مدينة املك عبد العزيز للعلوم والتقنية ‏ النظمة العربية للترجة 


اندریا دي لوتشیاء فیلومینا فيروتشي 
جيني تورتوراء ماريزيو توتشي 


سلسلة كتب التقنيات الاستراتيجية والحقدّمة 


1 


1- 2 مفاهيم أساسية n‏ 
1 3 البدايات ssn‏ 
1- 4 اكتساب المرونة n‏ 


3-4-1 المكونات والتوزيم sese‏ 
1 5 ترکیب البرمجيات في العالم المفتوح 
1- 1-5 حيز التنسيق الشامل sss‏ 


التركيبي ا 
1-2-2 مشكلاث الإفراط فى نطاق العمل 
2-2-2 مشكلات تتعلق بالمنهجية المغلقة 


3-22 منهجية عائلة المنج الث ر كيبية ا 
4-2-2 الفروقات الأساسية في المنهجية التر كيبية ا 
2- 3 المكرنات والشرائح الهيكلية n‏ 
2 1-3 تقنية المكوّنات . 
2 2-3 الشرائح الهيكلية والمكوّنات 
2 3-3 الشرائح الهيكلية واختبار التكامل n‏ 
4-3-2 تبعیات المكوّن esses‏ 
5-3-2 أمثلة ss‏ 


4-2 معوقات بحثية لطريقة المعالجة التركيبية 


1-4-2 إدارة المتطلبات اللامركزية ... 

2-4-2 إدارة الجودة والهيكلية ا 

3-4-2 تكنولو جيا المكوّناث البرمجية .. 

4-4-2 العملية وقضايا التنظيم ا 

5-2 الملخص ا 
المراجم ا 

3 تعليم أتماط التصميم . 
3 1 المقدمة ا 
2-3 تصميم لعبة الكويكبات ا 


r. Solid Body : عgill‎ 4-2-3 
a. Asteroid : عgill‎ 5-2-3 
r BigAsteroid : ع‎ gill 6-2-3 
ا‎ SmalAsteroid : ع‎ gill 7-2-3 
n SpaceShuttle : اللرع‎ 8-2-3 
Rocket :عgill‎ 9-2-3 
ss GameBoard : gill 10-2-3 
es Referee :عgill‎ 11-2-3 


SpaceShuttleController : gill 12-2-3 


3-3 تنزيل لعبة الكويكبات وتشغيلها ا 
4-3 التمرين الأول: نمذجة نمط المشاهد 0 


1-4-3 نموذج حل التمرين الأول n.‏ 


3 5: التمرين الثاني : رمج Observer Pattern‏ 


1-5-3 نموذج حل التمرين الثاني ا 


3- 6: التمرين الثالث: نمذجة نمط الموائم .. 


1-6-3 نموذج حل التمرين الثالث ا 
7-3 التمرين الرابع : برمجة Adapter ۴a)e۲۸‏ .. 


1-7-3 نموذج حل التمرين الرابع nenn‏ 


3 8 التمرين الخامس: نمذجة نمط الاستراتيجية 


1-8-3 نموذج حل التمرين الخامس ns‏ 


9-3 التمرين السادس : برمجة نمط الاستراتيجية 


7 
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1-9-3 نموذج حل التمرين السادس nnn‏ 
3 10 الخبرات والاستنتاجات sens‏ 


الجزء الثاني 
الأساليب الحديثة 


تأثير هندسة البرمجياث أدوانية التوجه 


في الحوسبة خدمية التوجه ا 


2-4 النظم الأدواتية وهندسة البرمجيات أدواتية التوجه .. 
3-4 تأثير الأدوات فى الهيكليات خدمية التوجه a.‏ 


4-4 الهيكاية القائمة على النماذج لخدمات الأدوات الشبكية a‏ 


4- 5 تنسيق الأدوات والتزامن فى هيكلية خدمات الويب 


4- 6 منهجية توصيف هيكلية خدمات الويب es‏ 
7-4 الاستنتاجات ا 


2-5 تأثير التصميم كائني التوجه في الاختبار ا 
5 3 تقنيات الا ختبار القائمة على المواصفات n‏ 


5 4 اختبار النوع الداخلي بلغة النمذجة الموحدة U M1‏ 


5- 5 اختبار النوع الداخلي في لغة النمذجة الموحدة .... 
5 6 تقنیات الاختبار الجبري ees‏ 
7-5 الاختبار المحدد بالشيفرة البرمجية ا 


5 8 الاختبار الهيكلي للنوع الداخلي ا 
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5- 9 الاختبار الهيكلي للنوع البيني n‏ 


10-5 الاختبار فى ظل وجود التوارث 
11_55 اختبار الانحدار eens‏ 


5 12 الاستنتاجات ا 


لغة التمذجة الموحدة والأساليب النظامية : 

دراسة حالة استخدام ا 

1-6 مقدمة عامة e‏ 

6 2 نظرة منحازة إلى لغة النمذجة الموحدة 

ForLySA 3-6‏ ا 
1-3-6 اللموذج الثابت ا 


2-3-6 النموذج الديناميكي 
3-3-6 لغة التو صيف 


7 2 أساسیات الويب ا 
7 3 هندسة البرمجيات وتطبیقات الويب ens‏ 
7 1-3 ثابت - دینامیکی _ نشط r.‏ 
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7 2-3 نمط تصميم متحكم عرض النموذج ens‏ 
7 3-3 أطر عمل تطبيقات الويب ا 


7 4-3 إصدار تطبيق ‏ 
7 4 التوجهات الحالية ... 


1-4-7 تو جه التطبيق : 


لویب ا 


r. المشاركة‎ 


2-4-7 الانتقال من سطح المكتب إلى الويب r‏ 
3-4-7 من صفحات الويب إلى خدمات الويب ess‏ 


4-4-7 سطح المكتب 
7 5 التوجهات المستقبلية 


1-5-7 قضایا التصفح 


الدلالى الاجتماعى ا 


7 2-5 البنية التحتية للشبكات ns‏ 


الجزء الثالث 


تقنيات تطؤر البرمجيات 


الترحيل إلى خدمات الويب 


1-8 القوى التي تقود عملية الترحيل esses‏ 
1-1-8 تغْيّر التكنولوجيا n‏ 


2-1-8 تغْيّر الأعمال 
2-8 ظهور خدمات الويب 
3-8 توفیر خدمات الويب 


1-3-8 شراء خدمات 


الويب ا 


8 2-3 استفجار خدمات الويب n‏ 
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8 3-3 استعارة خدمات الريب ess‏ 
4-3-8 بئاء خدمات الويب 
5-3-8 استعادة خدمات الويب ns‏ 
4-8 التنقيب عن خدمات الويب ا 
1-4-8 اكتشاف خدمات الويب المحتملة ا 
2-4-8 تقييم خدمات الويب المحتملة ا 
3-4-8 استخراج الشيفرة البرمجية لخدمة الويب ا 
4-4-8 تكييف شيفرة خدماث الويب e‏ 


1-5-8 تجهيز برامج الإنترنت بواجهة بصيخة 1× . 
8- 2-5 تجهيز البرامج الفرعية بواجهة n. ×١1‏ 
8- 3-5 ٹحویل 1× إلى کوبول وبالعکس ns‏ 
8 4-5 عملية الأداة n‏ 
8- 6 الخبرة العملية ا 


2-2-9 تصور قيم المقاييس المتعددة لإحدى الإصدارات 


3-2-9 تصور قيم قياسات متعددة لإأصدارات متعددة .... 


9 3 عرض تطور میزات النظام البرمجي ns‏ 
1-3-9 بيانات الميزات والتعديلات وأخطاء النظام 0 
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9 2-3عرض المشروع -إبراز تقارير الأخطاء 
على هيكلية الفهرس n‏ 


: تقارن تقرير الخطأا بين خصائص‎ 3-3-9 
eens Html gy Httpsy Mozilla Http 


4-3-9 تقارير الأخطاء المتقارنة 
بين خصائص وlılıÎت sss Mozilla‏ 


1-4-9 يانات التعديل sss‏ 
2-4-9 العروض الكسيرية . 
3-4-9 تصنيف الملفات المصدرية مع العروض الكسيرية ا 
5-9 عرض تقارن التغيير ا 
1-5-9 بیانات تقارن التغيير . 
9 2-5عروض seen EvoLens‏ 
3-5-9 التصور الرسومي المتداخل ا 
4-5-9 تقارن التغيير الانتقائي 
6-9 أعمال ذات علاقة es‏ 


الجزء الر ابع 


الاختبار التجريبي في هندسة البرمجيات e‏ 
10 1 مقدمة ا 
2-0 الدراسات التجريبية n‏ 


1-2-0 مقدمة عامة sss‏ 

0 - 2-2 استراتيجيات الاستقصاءات التجريبية 
3-2-0 مخاطر ومهددات الاستقصاء عن الصلاحية ا 
4-2-0 إرشادات تو جيهية للتجربة ا 

0 - 3 الدراسات التجريبية لعلم هندسة البرمجيات 
1-3-0 لمحة عامة ا 

0 2-3 تكرار الاستقصاء التجريبي ا 

0 3-3 الاستقصاءات التجريبية لإنتاج المعرفة ا 

0 - 4 الاستقصاء التجريبي لقبول الابتكار  .‏ 
0 5 بناء الكفاءات من خلال الاستقصاء التجريبي es‏ 
1-5-0 مقدمة عامة esses‏ 
2-5-0 أعراض التقادم . 

0 3-5 الهندسة العكسية ا 

0 - 4-5 الاأستعادة ا 

0 5-5 إعادة التصميم ا 
6-5-0 الملخص e‏ 
0 - 6 الاستنتاجات ا 
المراجع n‏ 
1 آساسيات المنهجات السريعة ا 
11 1 مقدمة Sess‏ 
2-1 المتهجيات السريعة ns‏ 
3-1 بيان منهجية التطوير السريع ا 
1 4 البرمجة القصرى ۶× sess‏ 
1-4-1 بنية فرق العمل في منهجية XP‏ ا 
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2-4-1 إدارة المتطلبات في n XP‏ 


3-4-1 مقدمة لعملية التطوير بمنهجية ۴× .... 


4-4-1 مقارنة منهجة ۴× بالمتهجيات الأخرى 


5-4-1 آليات التحكم في منهجية e XP‏ 

5-1 دعم الأدوات في منهجية XP‏ ا 

1 _ 6 الاستنتاجات ا 
المراجع ا 
مۇلقو ومحررو الكثاب ا 
ثبت المختصراث sss‏ 
ثبت المصطلحات r.‏ 
فهرس ا 
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تعديم 


سلسلة كتثب التقنيات الاستراتيجية 


مبادرة الملك عبد الله للمحتوى العربي 


يطيب لي أن أقدم لهذه السلسلة التي جرى انتقاؤها في مجالات تقنية ذات 
أولوية للقارئ العربي في عصر أصبحت فيه المعرفة محركاً أساسياً للنمو 
الاقتصادي والتقنى» ويأتي نشر هذه السلسلة بالتعاون بين مدينة الملك 
عبد العزيز للعلوم والتقنية والمنظمة العربية للترجمة» ويقع في إطار تلبية عدد 
من السياسات والتوصيات التي تعنى باللغة العربية والعلوم» ومنها: 

أولاً: البيان الختامى لمؤتمر القمة العربى المنعقد فى الرياض 1428ه 
7م الذي يؤكد ضرورة الاهتمام باللغة العربيةء وأن تكون هي لخة البحث 
العلمي والمعاملات حيث نص على ما يلي: (وجوب حضور اللغة العربية في 
جميع الميادين» بما في ذلك وسائل الاتصال» والإعلام» والإنترنت وغيرها). ‏ 

ثانياً: «السياسة الوطنية للعلوم والتقنية؛ في المملكة العربية السعودية التي 
انبثق عنها اعتماد إحدى عشرة تقنية إستراتيجية هي: المياه» والبترول والغازء 
والبتروكيميائيات والتقنيات المتناهية الصغر (النانو)ء والتقنية الحيوية» وتقنية 
المعلومات» والإالكترونيات والاتصالات والضوئيات» والفضاء والطيران» 
والطاقةء والمواد المتقدمة» والبيئة. 

ثالقاً : مبادرة الملك عبد الله للمحتوى العربى التي تفعْل أيضاً ما جاء فى 
البند أولاً عن حضور اللغة العربية فى الإنترنت» حيث تهدف إلى إثراء 
المحتوى العربي عبر عدد من المشاريع التي تنفذها مدينة الملك عبد العزيز 
للعلوم والتقنية بالتعاون مع جهات مختلفة داخل المملكة وخارجها. ومن هذه 
المشاريع ما يتعلق برقمنة المحتوى العربي القائم على شكل ورقي وإتاحته على 
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شبكة الإنترنت» ومنها ما يتعلق بترجمة الكتب الهامة» وبخاصة العلمية» مما 
يساعد على إثراء المحتوى العلمي بالترجمة من اللغات الأخرى إلى اللغة 
العربية بهدف تزويد القارئ العربي بعلم نافع مفيد. 

تشتمل السلسلة على ثلائة كتب في كل من التقنيات التى حددتها «السياسة 
الوطنية للعلوم والتقنية). واختيرت الكتب بحيث يكون الأول مرجعاً عالمياً 
معروفاً فى تلك التقنية» ويكون الثانى كتاباً جامعياًء والغالث كتاباً عاماً موجها 
إلى عامّة المهتمين» وقد يغطى ذلك كتاب واحد أو أكثر. وعليه» تشتمل 
سلسلة كتب التقنيات الاستراتيجية والمتقدمة على ما مجموعه ثلائة وثلاثون 
كتاباً مترجماً» كما خصص كتاب إضافي منفرد للمصطلحات العلمية والتقنية 
المعتمدة في هذه السلسلة كمعجم للمصطلح. 

ولقد جرى انتقاء الكتب وفق معايير منها أن يكون الكتاب من أمهات 
الكتب في تلك التقنيةء ولمؤلفين يشهد لهم عالمياًء وأنه قد صدر بعد عام 
0 وأن لا يكون ضيق الاختصاص بحيث يخاطب فثة محدودة» وأن تكون 
التسخة التي يترجم عنها مكتوبة باللغة التي آلف بها الكتاب وليست مترجمة عن 
لغة أخرى»ء وأخيراً أن يكون موضوع الكتاب ونهجه عملياً تطبيقياً يصب في 
جهود نقل التقنية والابتكار» ويساهم في عملية التنمية الاقتصادية من خلال 
زيادة المحتوى المعرفي العربي. 

إن مدينة الملك عبد العزيز للعلوم والتقنية سعيدة بصدور هذه المجموعة 
من الكتب» وأود أن أشكر المنظمة العربية للترجمة على الجهود التي بذلتها 
لتحقيتق الجودة العالية في الترجمة والمراجعة والتحرير والإخراج» وعلى حسن 
انتقائها للمترجمين المتخصصين» وعلى سرعة الإنجاز» كما أشكر اللجنة 
العلمية للمجموعة التى آنيط بها الإشراف على إنجازها فى المنظمة وكذلك 
زملائي في مدينة الملك عبد العزيز للعلوم والتقنية الذين يتابعون تنفيذ مبادرة 
الملك عبد الله للمحتوى العربي. 


الرياض 20/ 3/ 1431 ه 


رئيس مدينة الملك عبد العزيز للعلوم والتقنية 
د. محمد پن إبراهیم السويل 
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مقدمه 


«استشمر وقتك قي تطوير نفسك من خلال الاطلاع على ما كتبه 
الآخرون» بحيث تكتسب بسهولة خبرات ومعارق ما عانى وتعب 
الأخرون قي تحصيله». 


سقراط 


تۇد ثر البرمجيات في حياتنا اليومية بشكل كبير»ء وتعم مجتمعاتنا المدنية 
باستمرا . توفر الابتكارات المتواصلة في تكنولوجيا المعلومات والاتصالات 
فرصا جديدة وتزيد مدى التطبيقات التي يمكن الحصول عليها. تشكل هذه 
الاختراعات تحديات تقنية وعملية جديدة لمهندسي البرمجيات الذين يجدون 
الحلول لاستشمار التكنولوجيا الجديدة بصورة أفضل وتطوير أنواع جديدة من 
التطبيقات البرمجية. في الوقت ذاته» يجب على مهندسي البرمجيات صيانة النظم 
البرمجية المستخدمة حاليا وتطويرها حتى تصبح متوافقة مع التغيرات المطلوبة 
على المتطلبات» إضافة إلى استثمار الفرص التي توفرها التكنولوجيا الجديدة 
بأكمل صورة. نتيجة لتطور البرمجيات» ازداد حجم ودرجة تعقيد النظم البرمجية 
بصورة مطردةء ما أدى إلى زيادة التحديات التي تواجه عمليات تطوير البرمجيات 
وصيانتها أكثر وأكثر من ذي قبل» بحيث يتطلب ذلك وسائل محسنة. 

إذاً يمكننا القول إن هندسة البرمجيات هي نظام ديناميكي للغاية يجب أن 
يتطور باستمرار عن طريق البحث عن وسائل وآدوات ومنهجيات جديدة حتى 
تصبح عمليات تطوير البرمجيات وصيانتها أكثر موثوقية وكفاءة. يجب أن تؤخذ 
التبادلات الحرجة المرتبطة بالتكاليف والجودة والمرونة بالحسبان. لهذا السبب» 
تُعتبر هندسة البرمجیات اليوم إحدى مجالات البحث الأكثر متعة وتحفيزاً 
والأكثر ربحاًء كما إن لها تأثيرات عملية مهمة على صتاعة البرمجيات. 
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يلقي هذا الكتاب الضوء على بعض آخر المستجدات فى حقل هندسة 
البرمجيات. تتكرّْن فصول الكتاب من بعض المحاضرات التعليمية التى حاضر 
فيها عدد من رواد البحث المعروفين دولياً في أول ثلاث محاضرات في الندوة 
الدولية الصيفية التي نظمتها جامعة ساليرنو في إيطاليا حول هندسة البرمجيات. 


لا يهدف هذا الكتاب إلى شمول جميع مواضيع هندسة البرمجيات» لكن 
يهدف إلى تقديم طائفة جيدة من البحوث الحالية في مجال هندسة البرمجيات التي 
تتعامل مع بعض المواضيع الأكثر ارتباطاً وتطوراً في المجتمع العلمي .هذا الكتاب 
مخصص لطلاب الدراسات العليا الذي يرغبون فى التعمق فى هذا الحقل» إضافة 
إلى أهميته للباحشين الذي يعملون في مجالات هندسة البرمجيات المختلفة. 

تم تنظيم هذا الإصدار في آربعة أجزاء: هيكليات البرمجية» الأساليب 
والتقنيات الحديثة في تطور البرمجية وإدارة العمليات . 


يتضمن الجزء الأول» في فصوله الثلائةء تصميم هيكلية البرمجية» وهو 
نشاط حاسم مهم في تطوير النظم البرمجية. فهو يركز على تأسيس الهيكلية الكلية 
للنظام البرمجي» وذلك بتعريف عناصر النظام الأساسية والترابط بينها. وهو يوقر 
فكرة نظرية مهمة تساعد في فهم تعقّد النظام. في السنوات القليلة السابقةء 
تطورت هيكايات البرمجيات من كونها بُنى معرّفة مسبقاً متراصة ومركزية لتصبح 
غير مركزية وموزعة» وتتكوّن من عناصر ومكونات متحدة بصورة ديناميكية. 


يركز القصل الأول على هذا التطور من منظور تطور آليات تركيب 
البرمجيات» والمقصود هنا طريقة تركيب النظام ككل عن طريق ربط مكوتاته 
بعضها ببعض. يبيّن هذا الفصل كيفية تطور آليات الربط من خطط ثابتة إلى 
خطط ديناميكية ذات قابلية تغْيّر عالية وفقاً للاكتشاف والتفاوض والتحسين. كما 
يتضمن الفصل الأول قائمة قصيرة من التحديات المهمة التي لابد أن تكون 
جزءاً من الأجندة المستقبلية لأبحاث هندسة البرمجيات. ٠‏ 

يركز الفصل الثاني على مجموعات المنتجات البرمجية التي حققت قبولاً 
واعتماداً واسعاً في صناعة النظم» وأصبحت جزءأ لا يتجزأً منه. لا تقوم العديد 
من الشركات بتطوير البرمجيات من نقطة الصفرء لكنها تركز على القواسم 
المشتركة بين المنتجات المختلفة وتضمَنها في هيكلية المنتج الذي تعمل على 
تطويره مع مجموعة من الموجودات ذات العلاقة التي يمكن إعادة استخدامها. 
يحدد هذا الفصل العديد من التحديات التي تشكلها زيادة مدى خطوط المنتجات 
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التاجحة وتقدم مفاهيم جديدة للوصول إلى خطوط المنتجات البرمجية. 


يركز الفصل الثالث على حلول أنماط آو قوالب التصاميم التي عالجها 
المطؤّرون عبر الوقت لحل طائفة من مشكلات التصميم المتكررة» ويعنون 
عمليات تطوير الأنماط كائنية التوجه التي يصعب فهمها وذلك بتوفير عرض 
عملي من خلال دراسة حالة. يتوفر في هذا الفصل سلسلة من المتطلبات غير 
الوظيفية ذات درجة صعوبة متزايدة للعبة تفاعلية» كما تتوفر أنماط التصميم 
كالمراقب (ءءعءط0) والموائم (ءءامهف4) والاستراتيجية (رعهاةء)5) والمصنع 
المجرد (راهاعة۴ اعوإstاA)‏ بهدف توفير حلول لهذه المتطلبات. 


يشتمل الجزء الثاني على بعض الأساليب الحديثة كالأدوات البرمجية 
(sاAgen).‏ والحوسبة خدمية التو جه (عcomputin »)Service-oriented‏ واختبار 
النظم كائنية التوجه؛ والأساليب الرسمية (ولهطاءص لوص۳٣ه۴)»‏ وتطوير تطبيقات 
الويب (ا«عصمهام۷مل ا۷6). يناقش الفصل الرابع تأثير هتدسة البرمجيات 
أدو اتية llٿg )A gent Oriented Software Engineering - AOSE) a+‏ فى الحوسبة 
خدمية التوجه. النظام الأدواتي هو طريقة للتفكير في الأنظمة التي تتكون من 
كوائن نشطة وأدوات وسلوكها الجماعي. إن المجاز في الأداة فاعل في بناء 
البرمجية التي ستعمل ضمن ُظم مرتبطة بشبكة معقّدة» حيث ينعدم التحكم 
الشامل. بشكل خاص» أخذ المؤلفون فى الحسبان بعض الأفكار الرئيسة 
لمفهوم الهيكلية خدمية التوجه (804) في سياق التقنيات الخاصية بالأدوات 
وذلك لتنسيق خدمات الشبكة ومكوناتها. 

ييّن الفصل الخامس مسألة جودة البرمجيات» ويركّز على الأساليب الحديثة 
لاختبار الْنّظم كائنية التوجه. اختبار البرمجيات نشاط حاسم» وهو ضروري 
لضمان دقة الاعتمادية على البرمجية. وعلى الرغم من أن النموذج كائني التوجه 
يتيح تجنب بعض المشكلات المرتبطة بالبرمجة الإجرائية» فهو يعرف بعض 
المشكلات التي لم تستطع أساليب الاختبار التقليدية تحديدها. في هذا الفصل؛ 
يقدم المؤلفون أحدث الحلول التي قدمتها الأبحاث الخاصة لاختبار النظم كائنية 
التوجه التي تتغلب على المشكلات الناتجة من بعض خصائص الئظم كائنية 
التوجه كالسلوك المعتمد على الحالة والتضمين والتوارث وتعدد الأشكال. 


يوفر القصل السادس تقارير عن مشروع بيثات التصميم للتطبيقات الشاملة 
(DEGAS)‏ الذي موله الاتحاد الأوروبي» ويهدف هذا المشروع إلى دمج 
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استخدام لخة النمذجة الموحدة )0M1(‏ لتصميم التطبيقات الشاملة مع الأساليب 
الرسمية لتحليلها والتحقق منها. تتكون هذه الأنظمة الحديثة من أجهزة حاسبة 
موصولة من خلال شبكات الحاسوب. هذا وتعتبر عمليات التحليل والتحقق من 
أمن بروتوكولات الاتصال المستخدمة في مثل هذه الأنظمة الموزعة آمراً غاية 
في الأهمية. يستشمر هذا المشروع منهجاً يعتمد على عملية حسابية لتحديد 
النموذج السلوكي لأمن النظام الذي تم تنفيذ عمليات تحليل مكملات الجوانب 
البنيوية له على نماذج لغة النمذجة الموخدة. يلقي هذا القفصل الضوء على بعض 
المظاهر المرتبطة بلغة النمذجة الموخدة التي تمل تدوينا تصويرياً معياريا 
لتحديد وبناء وتوثيق بيانات النظام البرمجي. تم عرض إطار عملي يدعم مصمم 
النظام في تحديد البرتوكولات التي يجب تحليلها للوقوف على الخروقات التي 
قد تحدث في عمليات التحقق في نماذج لغة النمذجة الموحدة. 

يراجع الفصل السابع الاتجاهات الحالية والمستقبلية في تطوير التطبيقات 
التي تعمل من خلال شبكة الإنترنت وتختبرها من وجهة نظر هندسة البرمجيات. 
لا شك أن شبكة الإنترنت هي إحدى أهم الاختراعات التي ظهرت في العقد 
الأخير من القرن الماضي» التي أثرت في حياتنا اليومية بشكل كبير. إن الارتقاء 
المطرد في تكنولوجيا المعلومات والاتصالات بيّن التطور السريع في شبكة 
الإنترنت» وفي الوقت نفسه وبصورة عكسيةء فإن التطور السريع في الإنترنت 
قد بيّن الارتقاء المطرد في تكنولوجيا المعلومات والاتصالات. كان عقد واحد 
من الزمان كافياً لنقل شبكة الإنترنت من كونها مجرد مستودع لعدد هائل من 
الصفحات المستخدمة للوصول إلى المعلومات الثابتة لتصبح منصة فاعلة لتطوير 
وتشغيل ونشر العديد من التطبيقات. في الواقع» تتیح تقنيات الإنترنت ولغات 
البرمجة والمنهجيات الحديثة إنشاء تطبيقات ديناميكية توفر نموذجا جديدا 
للتعاون والتشارك بين عدد هائل من المستخدمين. يركز الفصل السابع تحديداً 
على التطورات التي طرأت على تقنيات التصفُح» وعلى خادم شبكة الإنترنت 
Serve(‏ طWe)»‏ وعلى البنى التحتية لشبكات الحاسوب» وعلى مستوى 
التطبيقات واتجاهات هندسة البرمجيات. 

يتضمن الجزء الثالث التقنيات المستخدمة فى تطور البرمجيات. إن الطبيعة 
الديناميكية للبرمجيات هي إحدى أهم ممیزاتهاء ليس ذلك فحسب. بل إنها 
إحدى أهم أسباب تعقيد البرمجية. في الواقع» تحتاج البرمجيات إلى تطور 
مستمر لتلبي المتطلبات المتغيّرة في هذا العالم» ولتشمل التقنيات المبتكرة. ما 
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الفصل الثامن فَيْعّنون الأمور التي قدمتها الهيكليات خدمية التوجه التي تمثل 
أحدث التغيرات في التكنولوجيا محددة بذلك انفصالاً جذرياً عن التقنيات 
السابقة. يوضح هذا الفصل الاستراتيجيات المختلفة لتزويد الهيكلية خدمية 
التوجه بخدمات شبكة الإنترنت ويركز على كيفية استعادة خدمات الإنترنت من 
التطبيقات المستخدمة حالياً. كما يلقي هذا الفصل الضوء على العديد من قضايا 
البحث التي تستحق التحقق منها في هذا السياق. 


يلقي الفصل التاسع الضوء على مشكلة تحليل تطور النظم البرمجية 
للحصول على معلومات عن أسباب وتأثير التغيرات المعيّنة» وللحصول على 
صورة واضحة عن المشكلات المتعلقة بخصائص معيّنة. إن ذلك أمر حاسم في 
التعامل مع زيادة درجة تعقد وسوء الهيكلية» ويتطلب تقنيات فاعلة لنقل 
المعلومات ذات العلاقة التي توجد ضمن كمية هائلة من البيانات. يقدم هذا 
الفصل بعض التقنيات التصورية التي تتيح تحليل جوانب مختلفة للنظم البرمجية. 


آما الجزء الرابع فيركز على إدارة العمليات وهي موضوع آخر رئيس في 
هندسة البرمجيات. في الواقع» تم إدراك حقيقة أن جودة النظام البرمجي تقار 
بشكل كبير بجودة العملية اتد لقطویر النظام وصيانته. إدارة العمليات 
تعني استخدام المهارات والمعرفة والأدوات والتقنيات لتعريف وقياس العمليات 
والسيطرة عليها وتحسينهاء وذلك للتحقق من جودة النظم البرمجية بطريقة 
تحقق كفاءة من ناحية التكاليف. . في هذا السياقء تؤدي الاختبارات التجريبية 
المبئية على الملاحظة دوراً مهماً في نقل نتائج أبحاث هندسة البرمجيات إلى 
عمليات صناعة البرمجيات ولتحويل الخبرات إلى معرفة. يقدم الفصل العاشر 
مفاهيم آساسية معروفة في الأدبيات» ثم يشرح الخطوات التي تنفذ في الأبحاث 
العلمية بدءاً من الملاحظة وحتى الخروج بنظريةء وكيفية دعم الأبحاث 
التجريبية لعمليات البرمجة والتطوير في هندسة البرمجيات. 


آما الفصل الحادي عشر وهو الأخير في الكتاب فيعرض أسس المنهجيات 
السريعة ومجموعة تقنيات التطوير التي ظهرت خلال عقد التسعينيات من القرن 
الماضى» التى صممت لتحدد بعض المشكلات التى تعترض عملية تطوير 
البرمجيات الحديثة» كتسليم المنتج في الوقت المحدد وحسب الموازنة التي 
وضعت له وبجودة عالية تحقق متطلبات واحتياجات العميل»› بما في ذلك 
منج )eXtreme Programming) (XP)‏ وهي أكثر المنهجيات شهرة» وقد قدمها 
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کیتت بيك .)K6٥۲ 8K(‏ تقدم هذه الأساليب بدائل ملائمة للمنتج الصحيح من 
دون هدر اوقت والجهد» في سياقات محددة ولمشكلات محددة. قام المۋلفوك 
بتحليل المفاهيم الرئيسة لمنهجيات التطوير السريعة والصعوبات التي تعترض 
تطبيقها بفعالية وكفاءة» مركزين تحديدا على منهجية ۴×. 
نقدّم امتناننا للكثير من الأشخاص الذين دعموا نشر هذا الإصدار 
مخصصين وقتهم وطاقتهم. بدايةّ» نشكر جميع المؤلفين لمساهمتهم القيّمة. كما 
نقدم شكرتا الجزيل لأعضاء اللجنة العامية على عملهم ودعمهم للدورة الدولية 
حول هندسة البرمجيات. كما نقذّم شكرنا لدائرتنا (دائرة الرياضيات والمعلوماتية 
في جامعة ساليرنو) لدعمهم ومساعدتهم المتواصلة. كما إننا ممتنون لكل من 
فوستو فاسانو (0ہھیھ۴ مtو۴۵u)ء‏ روکو اولیفیتو (٥۷eنا0 ۰)۸٥‏ سیرجیو 
دي مارتینو )ضMartin0 «(Serjio Di‏ رتا فرlنڊiyٽس ›(Rita Francens¢ê)‏ غياسبي 
سکانیللر (ie110ممھSc‏ eppeوGiu)‏ مونیکا سیبیللو (ەااناە؟ ›)M0«iea‏ فینسینزو 
دوفيميا ()ھDeufemi (Vincenzo‏ کارمن غرافینو (n0اہھإ‏ ع«نصھ٣)»‏ ومیشیل 
ريسي (ءن۴ مامط) الذين كانوا خير عون لنا في تنظيم الإصدارات المختلفة 
من الدورة. وأخيراًء» نود أن نشكر دار وايلي للنشر لمنحنا فرصة نشر هذا 
الإصدار وجميع فريق العمل ذوي العلاقةء ونخص بالذكر المحررة كايسي كريغ 
(ع )ie Cr‏ ومحرري المنتج لیزا فان هورن (۸ه٣ ۷۵٣‏ aونا)‏ من دار وايلي 
للنشر وباول بيني (yعصەe‌8‏ اس ھ۴٣)‏ وہرافیتا باتیل (1٤ا۴‏ a«نہهإ۴)‏ من دار 
نامل أن تستمتع عزيزنا القارئ بقراءة هذا الكتاب» وأن تجد فيه ما يفيدك 
في عملك. كما نتمنى أن نكون قد عالجنا المواضيع التي تساعدك في أبحائك في 
هندسة البرمجيات» وفي مساهمتك معنا في الندوة العالمية لهندسة البرمجيات. 
ندر ڀا دي (Andrea De Lucia) İi gl‏ 
فيلو ميئا فيرو تشي (Filomena Ferruci)‏ 
جيني ٹور ڈو ر (Genny Tortora)‏ 
ماريزيو توتشي (iءcںT Maurizio‏ 


کاتون الأول/ ديسمبر 2007 


22 


الجن الأرل 


هيڪليات البرمجيات 


1 


نشوء آليات ترڪيب البرمجيات: دراسة 


کار لو غیزي (Carlo Ghezzi)‏ 


)۴ل:مم٥‎ ۴٥| ٤¡( وفیلیبو باسیفیکي‎ 


1-1 مقدمة 


في الهندسة» يتضمن تطوير أي نظام تصميم هيكليته عن طريق تحليله إلى 
أجزاء منفصلة وتوضيح العلاقات بينها. تتيح هذه الطريقة للمهندسين الوقوف 
على درجة تعقيد النظام وذلك بتطبيق مبدأً فرق îتn.د (Divide-and-Conquer)‏ 
أي التركيز المتكرر على عدد محدود من الأنظمة الفرعية وعلى التفاعل ما بينها. 


بتاءَ على ما تقدم» قد يكوك ممكناً تحديد مرحلتين : تحديد سلوك الأجزاء 
منفصلة» وتحديد سلوك الأجزاء مجتمعة. إن تركيب هذه الأجزاء هو طريقة بتاء 
النظام كاملا عن طريق ربطها مع بعضها بعضاً. في هذه المرحلة» يركز 
المهندسون على كيفية تأسيس العلاقات بين الأجزاء بدلا من التركيز على 
تركيب داخلي محدد آو على سلوك المكوتات. 


تطورت النظّم البرمجية من نظم صغيرة وموخدة إلى نظم كبيرة وموزعة. 
بناء على ذلك» اكتسبت عملية تركيب النظم أهمية أكبر من ذي قبل تظراً إلى 
أن مهندسي النظم قد أدركوا أن تطوير البرمجيات لا يعتبر مهمة موحدة 
يضطلع بها شخص واحد» بل أن النظم البرمجية يجب أن توصف على آنها 
بتنى معقدة يتم الحصول عليها من خلال التنفيذ الحذر لعدد من آليات 
التركيب المحددة. 
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يمكن تحليل تركيب البرمجية باتجاهين: المعالجة وهيكلية المنتج. من 
وجهة نظر المعالجة» يجب آن يتم التركيب حسب طريقة بناء البرنامج في ما 
يتعلق بوحدات العمل والتنظيمات. آما من وجهة نظر هيكلية المنتج» فالت ركيب 
يعني طريقة بناء المنتجات في ما يتعلق بالمكونات وروابطها, 


يركز هذا الفصل على ثطور مبادئ تركيب البرمجيات وآلياتها خلال العقود 
الماضية. لقد سارت عملية التطور باتساق فى اتجاه زيادة المروئة: من مكوّنات 
ثابتة (مناها5) إلى مكرنات متغيرة (0ن4۳«ر0) ومن مكونات برمجية مركزية إلى 
مكونات وعتاصر برمجية غير مركزية. على سبيل المثالء لقد حدث تطور على 
مستوى شيفرة البرمجة من تراكيب برنامج موحد إلى تحليلات وظيفية وبرمجية 
كائنية التوجه. أما على مستوى أعلى ونظري أكثر فتطورت هيكليات البرمجيات 
من مركبات هيكلية مقترنة بشدة» كما في حالة الهيكليات متعددة الطبقات 
(ie-اMu)‏ إلى مكونات غير مركزية من نوع نظير - نظير. كما تطورت 
عمليات البرمجيات من عمليات ثابتة ومتعاقبة وموحدة إلى مخططات سير عمل 
سريعة وذات فترات منتظمة تكرارية وغير مركزية” . 
منظور تاريخي. يمكن اعتبار هذا الفصل بمثابة منهج تدريبي عن مكؤنات 
البرمجيات. 


تم تنظيم هذا الفصل كما يأتي. يتضمن القسم 2-1 بعض المفاهيم الأساسية 
عن مكوّنات البرمجيات. آما القسمان 3-1 و4-1 فيناقشان متى تظهر مشكلة 
مکرّنات البرمجیات» وکیف یمکن معالجتها مبدئياً. پرگز القسم 5-1 على بعض 
المساهمات العملية حول المفاهيم والأساليب والتقنيات التي تدعم تصميم تطور 
البرمجيات. يدور القسم 6-1 حول المرحلة الحالية» وهو يركز على أن التحدي 
الأساسي هو كتابة التطور البرمجي المتواجد في العالم المفتوح. فهو يعرف أين 
تكمن التحديات الأساسية» ويشرح بعض اتجاهات البحث الممكنة. 


1- 2 مفاهيم أساسية 


إن مفهوم الربط (ع«نفم81)" هو أمر أساسي دائم التكرار لفهم تركيب 
البرمجية على مستوى الشيفرة البرمجية والهيكلية. الربط هو تأسيس العلاقة بين 
العتاصر التي تكون هيكلية البرمجية. آما زمن الربط فهو الزمن الذي يتم عتده 
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تأسيس هذه العلاقة. على سبيل المثال» قد تستخدم هذه المفاهيم لوصف 
الخصائص الدلالية للغات البرمجة التى قد تختلف فى السياسة المتبناة لربط 
المتغيرات مع أنواعها وربط الأنواع الفرعية (#ومهءط5) بالأنواع الأم 
(ومووها۳) التي تتبع لهاء وربط تنفيذ الوظائف بتعريفاتها أو ربط الشيقرة 
البرمجية القابلة للتنفيذ مع الأجهزة الافتراضية. أما على المستوى الهيكلي» فقد 
یتم ربط الخادم )e۷(‏ بالعدید من الأجهزة التابعة (وtدهناح).‏ أزمان الربط 
النموذجية هي : فترة التصميم وفترة الترجمة وفترة النشر (أ١ءصرهام06)‏ وفترة 
التنفيذ (عصاآ «سR).‏ ربط فترة التصميم هوء مثلاء اتحاد يربط النوع في 
مخطط النوع في لغة النمذجة الموحدة مع الئوع الأم. آما ربط فترة الترجمة فيتم 


يقة مماثلةء ثمة حالات تُنفذ فيها عملية الربط بين وحدة معيّنة في 
البرنامج قابلة للتنفيذ والنقطة التي يتم عندها التنفيذ في النظام الموزع عند فترة 
النشر. وفي حالات أخرى» يتم تنفيذ الربط عند زمن التنفيذ وذلك لدعم إعادة 
تهيئة النظام. 
ومن المفاهيم المتعامدة الأخرى ما يعرف بثبات الربط. يكوك الربط 
ثابتاً (٥ناها8)‏ إذا لم بتخير بعد تأسيسه» وبخلاف ذلك» يكون ديناميكياً 
(منصة«ر2). في معظم الحالات» يكون ربط زمن التصميم وزمن الترجمة 
وفترة النشر ثابتاًء بينما يكون ربط زمن التنفيذ متغيرًء رغم ذلك» هناك بعض 
الاستشناءات. يكون الاختلاف الرئيس بين ربط زمن ما قبل التنفيذه وزمن 
التنفيذ : فربط زمن التنفيذ يضيف مرونة أكثر إلى النظام في ما يتعلق بربط زمن 
ما قبل التنفيذ وذلك بسبب سياسات التغبير التي يمكن آن تتبع لها عملية الربط. 
في حالة الربط الديناميكي» قد نفرق أكثر بين الربط الواضح والربط 
الأوتوماتيكي. في إحدى الحالاتء مثلاء يطلب المُستخدم من النظام تغيير 
الربط» ويحدد عنصراً جديداً يجب ربطه» بينما في حالة أخرى يكون للنظام 
استقلالية في تحديد متى يجب تغيير الربط»ء ويكون في هذه الحالة مزودا 
بآليات لتحديد العنصر الذي يجب ربطه. عملياًء هناك طائفة من الحلول 


(1) نستخدم هذا المصطلح بدلاً من المصطلح الأكثر شيوعاً افترة التجميع ءا اامهء؛ وهو مصطلح 


آکثر حصراً وذلك لشمول مظاهر معالحة في لغات برمجة أخرى كالمعالحة المسبقة (ومنووععإموءآم) وربط/ 
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الممكنة التي تتراوح بين ربط زمن التنفيذ الديناميكي الكامل وربط زمن ما قبل 
التنقيذ الثابت. 

هذا وقد تنطبق هذه المقاهيم على مستوى العملية أيضاً لوصف وتحديد 
كيفية تنظيم عملية تطوير البرمجية. على سبيل المثال» قد يربط أحدهم بين 
الأشخاص وأدوار وظيفية محددة (كمختبر النظام) بطريقة ثابتةء أو قد يتخير 
ذلك في آثناء تنفيذ عملية التطوير. بطريقة ممائلة لذلك» قد يتطلب إكمال 
مرحلة التطوير (كتفصيل ا مثلا) قبل البدء بالمرحلة التالية (كتابة الشيفرة 
البرمجية). في هذه الحالةء يتم تأسيس الربط بين مرحلة ما والمرحلة التي تليها 
من خلال مخطط تحكم متتالي معرف مسبقاً. وقد يقوم أحدهم بعنظيم 
المرحلتين كخطوتين متزامنتين مفصلتين. 

إن وصف الربط مفيد لفهم تطور البرمجيات» سواء تم بالطريقة التي يتبعها 
مهندسو النظم لتطوير البرمجيات أو بالطريقة التي يبنون بها هيكلية التطبيقات. 
لقد أدى هذا التطور إلى تحول النظم البرمجية من بنى ثابتة ومركزية وموحدة 
حيث يعرف الربط في زمن التصميم» بينما يكون مجمداً في أثناء دورة حياة 
النظام كلهاء إلى تصاميم ديناميكية وقياسية وغير مركزية وإلى عمليات تصميم› 
حيث يمكن تغيير الربط الذي يعرف بنى مقترنة على نحو غير محكم من دون 
توقف النظام» وقد يتخطى الحدود المشتركة بين الشركات. 

ومن الجدير بالاهتمام محاولة تحديد مصادر التطور والقوى المحركة له. 
إن التقدم الذي طرأ في تكنولوجيا البرمجيات هو قوى ذاتية بالطبع. في الواقع› 
توفر لغات البرمجة وأساليب التصميم الحديثة دعماً للربط الديناميكي والتغيّر 
المستمر. على كل حالء تشأت الحاجة إلى الديناميكية والتطور أساساً في بيئات 
العمل التي تنواجد ضمنها النظم البرمجية. آما الحدود بين هذه النظم البرمجية 
والبيئة الخارجية فهي عرضة للتغيير المستمر. لقد استخدمنا مصطلح «برمجيات 
العالم المفتوح» لوصف هذا المفهوم . في بدايات تطوير البرمجيات» وضع 
افتراض حصر البرمجيات في عالم مغلق. لقد افترض أن المتطلبات التي تحدد 
الحدود بين البيئة والنظام الذي سيتم تطويره كانت ثابتة بما فيه الكفاية ويمكن 
انتقاؤها مقدماً قبل بدء التصميم والبرمجة. بما إننا سنفسر ذلك في ما تبقّى من 
هذا الفصلء آثبت هذا الافتراض خطآه. فالبرمجيات تتواجد في عالم مفتوح 
بحيث تتغير الحدود في العالم الفعلي بشكل مستمر»ء حتى في أثناء كون 
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البرمجيات قيد الاستخدام. يتطلب ذلك تغيير السياسات الإدارية التي يمكن آن 
تدعم التطور خلال روابط فترة التنفيذ. 


1- 3 البدايات 

حتى عقد الستينيات من القرن الماضي ٠‏ كانت عملية تطوير البرمجيات 
مهمة يختص بها شخص واحد فحسب» كان على هذا الشخص فهم المسألة 
التي عليه حلها فهماً جيداًء ومن ثم كان المبرمج هو الشخص المتوقع 
والمستخدمين. كانت المشكلات التي توجب حلها أساساً ذات طبيعية رياضيةء 
وقد توفرت للمبرمجين معرفة في الرياضيات ما مکنهم من فهم المسائل التي 
طلب منهم حلها. كانت البرامج بسيطة نسبياً مقارنة بما هو متوفر في وقتنا 
الحاضرء كما تمت برمجة تلك البرامج بواسطة لغات برمجة ذات مستوى 
منخفض» ولم يكن هناك دعم للأدوات. أما بالنسبة إلى المعالجة» فلم يتبع 
مهندسو البرمجيات أي نموذج تطوير نظامي»ء لكنهم اتبعوا طريقة كتابة الشيفرة 
البرمجية وإصلاحها باستمرار» آي فترة برمجية تكرارية من كتابة الشيفرة 
وإصلاحها لتقليل الأخطاء. 

لقد أثبتت هذه الطريقة عدم جدواهاء ذلك بسبب () زيادة تعقد النظم 
البرمجية ر الحاجة إلى تطبيق الحوسبة»› لیس فی حل المسائل العملية فقط› 
بل أيضاً فى حل المسائل المرتبطة بمجالات أخرى» كإدارة الأعمال ومراقبة 
العمليات» حيث يكون فهم هذه المشكلات أقل من لو أنها كانت علمية. 

في بداية عقد السبعينيات من القرن الماضيء وبعد أن أصبح هناك إدراك 
لهندسة البرمجيات كموضوع علمي حاسم **» تم تطوير منهجية البرمجة التي 
تعرف G9 waterfall) Jil,‏ كتموذج عمليات مرجعي لمهندسي البرمجيات. 
كانت تلك محاولة لدمج مفهوم الانضباط وإمكانية التوقع في هندسة 
البرمجيات. تنفذ هذه المنهجية على شكل مخطط سير عمل ذي مراحل متعاقبة 
تبدأً بمرحلة تحديد المتطلبات تتبعها مرحلة التصميمء ثم مرحلة كتابة الشيفرة 
البرمجية» وأخيراً تكون مرحلة التحقق من فاعلية البرنامج هي المرحلة الأخيرة. 
كان تموذج المعالجة المقترح ثابتاً ولا يتغير: فقد كانت عملية التقسيم إلى 


(2) لطالعة موجز عن تاريخ هندسة البرمجيات» يمكن للقارئ الرجوع إلى المرجع 22. 
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مراحل وربطها في مرحلة واحدة محددة بدقة. كما إن عملية إنهاء مرحلة 
والخروج منها والدخول في المرحلة التالية مُعدة بدقةء حيث كان الهدف الحد 
من إعادة أي عمل في آي من المراحل المكتملة أو حتى إن كان ذلك غير 
مسموح به. كان الدافع الأساسي هو آن إعادة العمل - أي التغيرات التي تطلب 
لاحقا على البرمجية - سيكون على حساب الجودة» وسيتسبب في ارتفاع 
تكاليف البرمجة والتطوير» عدا عن أنه سيسبب تأخيراً في طرح المُنتج في 
السوق. أدى ذلك إلى استثمار الجهود في عمليات تحديد المتطلبات 
والخصائص وتحليلهاء التي يفترض أن تتوقف قبل البدء في البرمجة. 


ساعدت هذه المنهجية في وضع افتراضات ضمنية قوية جداً على المجتمع 
الذي سيتم تشخيل البرمجية فيه. لقد افترض أن هذا المجتمع ثابت غير متغيرء 
بمعنى أنه افترض أن متطلبات النظام لن تتغير. لقد كانت المشكلة في اختيار 
المتطلبات بشكل صحيح› بحيث تكون محددة تماما قبل البرمجة. المتطلبات 
المحددة بصورة كاملة ودقيقة تضمن عدم ظهور آي حاجة إلى إجراء أي تخيير 
في البرمجية في أثناء عملية البرمجية أو بعد تسليم البرنامج أو تسويقه. 


من الافتراضات الأخرى أن المؤسسات التي سيستخدم فيها البرنامج ذات 
بنية موحدة. لقد كانت تلك المؤسسات عبارة عن وحدات متفصلة ذات إدارة 
مركزية. وقد كان التواصل والتنسيق بين الشركات الموحدة محدوداً وغير حاسم 
للأعمال التي تقوم بها. لذا فقد كانت الحلول المركزية أمرا طبيعياً في ظل هذه 
الظروف. 


ياء على هذه الافتراضات› وعلى تقنیات تطویر البرمجيات التي کالت 
المتاحة في ذلك الوقت» طؤر المهندسون نظماً برمجية موحخدة ليتم تشغيلها من 
خلال أجهزة الحاسوب المركزية (ع«ه٣؟«نة).‏ ومع أن حجم البرامج تطلب 
مشاركة العديد من الأشخاص في جهود البرمجة إلا آنه أعطي القليل من 
الاهتمام بالهيكلية التي ثرتكز على تقسيم البرنامج إلى وحدات. أما عملية تطوير 
الوظائف بشكل منفصل فقد كانت مقيدة بفترة الترجمةء ولم تكن المميزات 
لزم الأمر. لذاء فإنه لإجراء تغييرء كان الأمر يتطلب وضع البرنامج في حالة 
عدم استخدام» إلى أن يتستى للمُبرمجين تعديل الشيفرة البرمجية» ومن ثم 
إعادة تجميع الوحدات وربطها وإعادة نشرها للاستخدام. إذاًء ونظراً إلى عدم 
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الاهتمام بالهيكلية التي ترتكز على تقسيم البرنامج إلى وحدات» كان من 
الصعب إجراء التغيير المطلوب» كما كان من الصعب توقع تأثير هذه التغيرات. 


1- 4 اکتساب المرونة 


إن الحاجة إلى إنجاز التغيرات التي تطلب على البرمجيات والتطور الذي 
طرأً على هندسة البرمجيات دعت إلى البحث عن منهجيات أكثر مرونة. أصبح 
من الواضح أن متطلبات النظام لا يمكن آن يتم جمعها وتحديدها مقدماً في 
معظم الظروف والحالات وذلك لأن العملاء لا يعرفون ما يتطابونه بالضبط 
مقدماً. حتى لو عرفوا متطلباتهم فإن هذه المتطلبات عرضة للتغييرء قد يكون 
ذلك قبل برمجة البرنامج بالكامل. يطرح هذا الأمر تساؤلاً حول التوقعات 
الضمنية التي يرتكز عليها نموذج الشلال. إضافة إلى ذلك» تحولت الهيكليات 
البرمجية لتصبح صعبة التعديل نظراً إلى أن الاقترانات المحكمة بين أجزاء 
البرمجية المختلفة من المستحيل فصل تأثير التغيرات في الأجزاء المقيّدة من 
البرنامج. ظاهرياً التغيرات البسيطة لها تأثير شامل في تكامل النظام ككل. 

أخيراً» أذى التطور في مؤسسات الأعمال إلى الحاجة إلى مزيد من 
المرونة. لقد تطورت بنى المؤسسات المركزية الموحدة لتصبح وحدات 
ديناميكية مستقلة وغير مركزية. كما تغيرت عمليات تطوير البرمجيات أيضاً لأن 
المكؤنات الجاهزة للاستخدام وآطر العمل المختلفة أصبحت متوفرة تدريجياً. 
أصبحت عمليات تطوير البرمجيات غير مركزية وموزعة على عدة مژسسات»› 
فهناك مطورو عناصر البرامج»ء وهناك من يقوم بدمج وحدات النظام. 

سنناقش في الأجزاء الأخرى من هذا الفصل أهم الخطوات والمساهمات 
التي تقود إلى الحصول على مستويات متزايدة من المرونة. 


1- 4 - 1 تصميم التغيير 


المساهمة المفاهيمية الأولى نحو تطور النظم البرمجية كانت مبدأ تصميم 
التغير وتعريف التقنيات التي تدعمه. اقترح بارناس (مه«عهم)” آنه يتوجب 
على مصممي النظم الاهتمام أكثر بمرحلة المتطلبات لفهم التغيرات التي قد 
تطرأً مستقبلاً على النظام. إذا كان بالإمكان توقع التغيير فإن التصميم يجب أن 
يحاول تحقيق هيكلية تضمن سهولة فصل تأثير التغيير ضمن أجزاء مقيّدة من 
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النظام. ومن أنواع التغيير التي يمكن آخذها بالحسبان مسبقاً: تغيير في 
الخوارزميات الحسابية المستخدمة لتنفيذ مهمة معيّنة» تغيير في عرض 
البيانات» تغيير في أدوات أو أجهزة معيّلة يستخدمها البرنامج ويتفاعل معها 
كالمجسّات والمحركات الميكانيكية. 


يتوسع بارناس في تقنية تصميم تُعرف بإخفاء المعلومات» ومن خلالها يتم 
تحليل البرنامج إلى وحدات» حيث يتم إخفاء معظم مصادر التغيرات المتوقعة 
على المتطلبات كأسرار في الوحدة» ولا يكون الوصول إليها من قبل الوحدات 
الأخرى متاحاً. 


ثمة فصل واضح بين واجهة الوحدة وتنفيذ الوحدة» يعمل على فك 
قرارات التصميم الثابتة المتعاقة باستخدام الوحدة من قبل وحدات أخرى من 
الأجزاء القابلة للتغيير والمختفية ضمنها. لا يتأثر مستخدمو الوحدة بالتغييرات 
طالما آنها لا تؤثر في واجهة الاستخدام. تتيح هذه الخاصية من خواص مبداً 
التصميم الفصل بين القضاياء وهذا مبدأً يدعم التصميم متعدد المستخدمين 
ويدعم تطور البرمجيات. 


يتيح إخفاء المعلومات تحليل تصميح النظم الكيرة | إلى وحدات متسلسلةء 
يكون لكل وحدة منها واجهة منفصلة عن التنفيذ. إذا تم تأسيس الربط بين الواجهة 
والتنفيذ بطريقة ثابتة ضمن فترة الترجمة ل بطريقة ثابتة من اتساق 
الواجهات مقابل التنفيذ ومقابل الاستخدام من قبل وحدات العميل. إن التحقق 
الثابت من شأنه أن يمنع بقاء الأخطاء غير معروفة في النظم بعد استخدامها. 


إن مفاهيم إخفاء المعلومات والواجهة مقابل التنفيذ أدمجت في لغات 
البرمجة» وقد دعمت التطرير المنفصل والتجميع المنفصل للوحدات في النظم 
الكبيرة”. مثال على ذلك» دعتا نأخذ بالاعتبار لغة البرمجة (4۵4) التي 
صمَمت في نهايات عقد السبعينيات من القرن الماضي. الوحدات في لغة 
البرمجة ,2 تعرف بالحزم» وهي تدعم إخفاء المعلومات» وفصل تجمیع 
الواجهات والتنفيذات. فحالما يتم تحديد واجهة وتجميعهاء فإنه يحون 
بالإمكان تجميع تنفيذ الواجهة وتنفيذ وحدات المستخدمين. عموماًء فإنه يمكن 
تجميع وحدة إذا كانت جميع الوحدات التي تعتمد عليها مجمعة أصلا. وهذا 
يتيح للمجمع أن ينفذ تحققاً من النوع الثابت بين الوحدات المختلفة (انظر 
الشكل 1 - 1), 
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Interface 


Component 
(module) 
implementation 


Interface 


Com ponent 
{module} 
Implementation 


type 
checking 


type 
checkıng 


Interface 


Component 
(module) 
Impiementatıon 


Interface 


Component 
{module} 
Implementation 


الشكل (1-1): هيكلية برنامج رآ إلى وحدات 


هناك الكثير من الأمثلة على لغات برمجة توفر خصائص مشابهة» ولو 
بشكل جزئي. على سبيل المثالء في لغة البرمجة € من الممكن فصل تعريفات 
النمافج الأولية للوظائف عن التنفيذ» ووضعها في ملفاث مختلفة (عن ملفات 
التنفيذ)» لكن ذلك ليس بالأمر المتطلب. بهذه الطريقةء من الممكن تعريف 
الواجهة المصدرة من قبل وحدة» بالرغم من آنه لا بمكن تحديد الوظائف الي 
تسثوردها الوحدة من وحدة أخرى بالضبط. 

مع أن التغييرات قد سيّلت مفاهيمياً إذا كانت مفصولة ضمن تنفيذات 
الوحدةء فإن هيكلية التنفيذ الناتجة ستكون ثابتة. فقد تم حل جميع الروايط قبل 
فترة التنفيذ ولا بمكن تغييرها ديناميكياً. لإجراء تغيير» يجب أن يعاد البرتامج 
كله إلى فثرة التصميم» بحيث تجرى التعديلاث ويتم التحقق منها من قبل 
عملية الترجمة» وبعد ذلك يعاد تشغيل النظام ضمن تهيئة جديدة. 


1- 4 - 2 لغات البرمجة كائئية التوجه 


كانت الطربقة المياشرة لإخفاء المعلومات مضمَنة في لغة وحدات وقرت 
دعماً محدوداً لتطور البرمجياث والثركيب المرن للنظم البرمجية. وفرث تقنيات 
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التصميم كائنية التوجه ولغات البرمجة خطوة كبيرة في هذا الاتجاه. إذ يهدف 
التوجه الكائني إلى توفير دعم للوحدات المستقلة والتطوير التزايدي؛ كما إنه 
يدعم التغيير الديناميكي. بناء على التصميم كائني التوجه»ء يتم تحليل النظام 
البرمجي إلى آنواع (8ءو14٣)‏ بحيث يتم تجهيز البيانات والعمليات» وتعرف 
آنواع نظرية جديدة من البيانات يتم توريد عملياتها من خلال واجهة النوع. 


من المساهمات الكبرى للغات البرمجة كائنية التوجه أن الربط بين عملية 
تتطلبها وحدة عمل تابم (1ممنا©) والتنفيذ الذي توفره وحدة خادم )Server)‏ 5ذ 
يتغير ديناميكياً في أثناء فترة التنفيذ. وهذه خاصية أساسية لدعم تطور البرمجية 
بطريقة مرنة. إضافة إلى ذلك» توفر معظم لغات البرمجة كائنية التوجه هذه 
الخاصية بطريقة تحافظ على أمن عملية التحقق من النوع الثابت* . 


مثال على ذلك»› دعنا نفترض وجود برنامج يستخدم في مجال الإإمدادات 
لمتابعة حاويات المواد. تتيح العمليات التي تختص بالحاويات للمستخدمين 
تحميل مادة إلى الحاوية والحصول على قائمة بالمواد التي تحويها وربط 
الحاوية بالوسيلة الناقلة التى قد تكون عبارة عن قطار أو شاحنة تحمل علیها 
الحاويةء أو قد تكون عبارة عن مساحة اصطفاف تخزن فيها الحاوية مؤقتاً. ثمة 
عملية تستخدم للحصول على موقع الحاوية الجغرافي ويتم تنفيذها عن طريق 
الطلب من الحاوية تحديد ذلك. موقع الاصطفاف ذو موقع ثابت» بينما يوجد 
وسائل معينة ليحدد كل من الشاحنة والقطار موقعهما ديناميكياً. لتفترض حدوث 
تطور على النظام بحيث تزود الحاويات بهوائي لنظام تحدید المواقع یمکن 
استخدامه لتحديد موقعها. يمكن تطبيق ذلك كتغير في تنفيذ العملية 
(«ەناومم_امع) التي تستخدم حاليا البيانات التي يوفرها نظام تحديد المواقع 
بدلً من طلب ذلك من الناقل. هذا ولن يتأثر المستخدم الذي يستخدم الحاوية 
بطريقة تنفيذ العملية الجديدةء إذ يتم توجيه تنفيذ العملية («ه0ن)اومم_اءع) إلى 
عملية معادة التعريف (الشكل 2-1) . 


بشكل عام» إذا أعطينا نوعاً يحدد طرازاً نظرياً من البيانات» فمن الممكن 
تحديد التغيير بواسطة الأنواع الفرعية (المشتقة من النوع الرئيس). يرتبط النوع 
الفرعي بشكل ثابت مع النوع الرئيس (النوع الأم) من خلال علاقة الوراثة. ومن 
ناحية آخرى» قد يكون للنوع الفرعي أنواع فرعية أخرى» وهذا ينتج تسلسلاً هرمياً 
من الأنواع. قد يضيف النوع الفرعي خصائص جديدة للنوع الأم (مثلاً عمليات 
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جديدة) و/ أو إعادة تعريف عمليات موجودة فيه. إن إضافة عمليات جديدة لا يؤثر 
في التوابع (وا«عنا۳) الموجودة أصلاً للنوع لأن هذه التوابع قد تهملها. كما إن 
إعادة تحديد عملية لن پؤثر في التوابع إذا فرضت لغة البرمجة المُستخدمة بعض 
القيود كما في لغة جافا (4۷[). ومن خصائص العركيب الأساسية التي تدهم 
التطور خاصيتا تعدد الأشكال (صونطمإمصراه۴) والربط الديناميكي. 


تشيح خاصية تعدد الأشكال تحديد متغيرات يمكن آن تشير إلى أنواع 
عديدة. أي إن الربط بين المثغير ونوع الكاثن الذي بشير إليه العثخير يُحدد في 
فترة التنفيذ. تحدد هذه المتغيرات (التي تعرف بالمتغيرات متعددة الأشكال) 
كمرجعية للنوعء وقد تشير إلى كوائن تتبع لأي من الأنواع الفرعية. بكلماث 
آخرى» بحدد الطراز الثابت من المتغير بواسطة نوع الكائن الذي تشير إليه 
حالياً. يمكن تحديد الطراز الديناميكي بواسطة أي من الأنواع الفرعية التابعة 
للنوع الذي يحدد الطراز الثابت. عن طريق الربط الديناميكي» يمكن تحديد 
العملية التي يتم استدعاؤها بواسطة النوع الذي يحدد طرازها الديناميكي. 


Container ct = new Container{} ; Container _| 
ct.getPosition{) ; و‎ 
binding 


ct = anyûbj .getContainer{)}; 
ct.getPosition() ; 


extension 


Container WithGPS 
HK FOSI1T10n 

binding +initGPS( }‏ 
الشكل (2-1): في فترة التفيلء لا يمكن التأكد من رقم إصدار ال لها" الذي 
سیتم اسندصاڙه 


إن المرونة التي تضمنها عملية الربط قد تسبب بعض المشكلات المتعلقة 
بالأمن: فبما إن العملية المستدعاة لا پمكن أن تحدد قي فثرة التجميم » فكيف 
يمكن ضمان استدعاتها بصورة صحيحة في فترة التنفيذ؟ تحتفظ معظم لغات 
البرمجة كاثنية العوجه» بما فيي ذلك جافاء بمنافع أمن النوع في سياق الربط 
الديناميكي عن طريق تقيد طريقة إعادة تسريف ال (04ا») في النوع الفرعي. 
نظراً إلى أن التحقق من الطراز بتم تنفيذه في أثتاء فترة التنفيذ من خلال النظر 
إلى الطراز الثابت للمتغير؛ فإنه يمكن وجود حل يتمثل في إعادة التعريف 
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المقيد وليس تخير واجهة ال (08طاهM)‏ الذي يتم إعادة تعريفه. وعليه يمكن 
أن يكوت تركيب البرمجية من نوع التحقق من الطراز بطريقة ثابتة حتى لو كانت 
الروابط بين الكوائن متغيرة ديناميكياً في فترة التنفيذ. 


1- 4 - 3 المكونات والتوزيع 

أصبحت المكرّنات الجاهزة للاستخدام“" متاحة لمطوّري البرمجيات. آدى 
ذلك إلى طلب إجراء تغييرات في الأساليب المستخدمة لتصميم البرامج: فقد 
استبدلت منهجيات التصميم التقليدية التي تعتمد على تحليل البرئامج من الأعلى 
إلى الأسفل جزئياً بمنهجية التكامل من الأسفل إلى الأعلى. وبمجيء المكونات 
الجاهزة للاستخدام أصبح تطوير العمليات غير مركزي» حيث تكون المؤسسات 
واضحة في عملية التطوير من حيث الكفاءة التي يمكن أن تتقدم بسرعة أعلى» 
ذلك أن أجزاء كبيرة من الحلول مدعومة بواسطة مكزنات قابلة لإعادة 
الاستخدام. تتضمن المسؤوليات غير المركزية أيضاً تحكماً أقل بالنظام كله وذلك 
بسبب عدم مسۇولية أي مۇسسة منفردة عنه. مثا إن تطور المكونات دراج 
خصائص جديدة أو لاستبدال خصائص موجودة صله لا کون ضمن سيطرة 
موحد النظام, تکون المكزّنات في الأغلب جزءاً من نظام موزع على عدة أجهزة. 
لا شك آن التوزيع خطوة كبرى من مظاهر تطور مكونات البرمجيات. بوجود 
التوزيع› يصبح الربط بين أحد المكونات والجهاز الافتراضي الذي ينمذ ذلك 
المكؤن قراراً تصميمياً مهماً. تأتي أهمية توزيع البرنامج على عدة أجهزة مرتبطة 
في الشبكة من الحاجة إلى أن تعكس طبيعة المؤسسة الموزعة في عدة مناطق 
والتي تستخدم ذلك البرنامج. غالباً ما يتم تجاهل الروابط بين وظائف الأجهزة 
في أثناء تطوير النظام» لكن يمكن نشرها في أثناء فترة النشر. 

في التظام الموزع» يتفذ الربط بين المكونات بواسطة وسيط. ومن 
أشهر الأمثلة على الوسيط ۸M1(‏ م«ةل)** (آي استدعاء المنهجية عن بعد 
الخاص د (Java‏ فهو يدعم هیکلیات الخادم - التابع بواسطة وسائل من 
استدعاءات عن بعد (الشكل 3-1). يمكن الوصول إلى كائن (۷4[) بواسطة 
أجهزة تعمل عن بعد كما لو كان تنفيذها يتم في الجهاز نفسه. يستدعي الجهاز 


(3) يتيح المرجمان 11 و27 تحليلاً متعمقاً لهذه القضاياء ويعطيان معايير عامة لأمن الئمط. 


36 


التابع ال (sلمطا)‏ كما لو أن يقوم باستدعائها في كائن محلي. يدرك وسيط 
M۲2‏ ) الرابط عن طریی تنظیم الطلب وإرساله عبر .)۳٥۴/۳۴(‏ ثم يشوم الجهاز 
الخادم باستقبال الطلب وتنفيذ الى (لهطاء) ويرسل النثيجة بالطريقة نفسها. وسن 
الأمثلة الأخرى على هيكلية وسيط طلب الكائن المشترك (0۸84ع) وهذه 
الهيكلية تدعم المكونات الموزعة المكتوية بعدة لغات برهمجة. قد يتم اعتماد 
سياسياث الربط لدعم التوزيم. ومن الاحتمالاث الممكنة تنفيذ ربط ثابث بين أحد 
المكؤناث وجهاز افتراضي في فثرة النشر. وقد يفكر أحدهم في الربط الديناميكي 
بين أحد المكؤنات وجهاز افتراضي في فترة النشر. وهذه هي الحال في إعادة تهيئة 
النظام الديناميكي الذي يهدف إلى محاولة تحقيق أفضل تناغم لاعتمادية وأداء 
البرنامج الموزغ عن طريق إعادة ربط المكونات بالشبكة في أثناء فثرة التنفيذ. 


ClientObjec 2 RemoteObject‏ الوصقف 
المنطقي 


الفا 
host‏ افيزياني 


remote object 


واجمة ل 


SûCket 


الشكل (3-1): التوزيع بين الوصف النطقي والوصف الفيزيائي مع الوسيط ۸۸1 ۸ه 


1- 5 تركيب البرجيات في العام المفتوح 

تشطور عملية تطوير البرمجيات نحو المنهجيات الأكثر مرونة وغير 
المركزية» حتى تدعم التطور المتطلبات المستمر. لقد تحقق ذلك عن طريق 
محاولة توقم التيير مسبقاً ما أمكن» وعن طرپق حجب أچڙاء كبيرة من التطبيق 
قيد الاستخدام بحيث لا تتأثر بالتغيير المطلوب تنفيذه في أجزاء أخرى. تعتبر 
هذه المنهجية ميدأ رئيساً في التصميم ويجب أن يضطلع يها مهندسو 
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البرمجيات. ومع ذلك فإن سرعة التطور في وقتنا هذا وصلت إلى مستويات 
غير مسبوقة» فالحدود بين النظم التي يتوجب تطويرها والعالم الحقيقي الذي 
تتفاعل معه هذه النظم تتخير باستمرار. في بعض الحالات› لا یمکن توقع 
التغييرء إذ يحدث التغيير في أثناء تشغيل النظام وعملهء والنظم التي تكون قيد 
التشغيل يجب آن تكون قادرة على التفاعل مع التغيير بطريقة منطقية. لقد طلقنا 
على ذلك «سيناريو العالم المفتوح؟ مسبقا. 


تحدث سيناريوهات العالم المفتوح في البرامج الحديثة كفهم المحيط 
¢Ambient Intelligence)‏ 7“ والحوسبة lلأnتخllة “(Pervasive Computing)‏ , 
في آطر العمل هذه» تكون نقاط التخمين متحركة وتتغير الطوبولوجيا الفيزيائية 
للنظام بشكل مستمر. كما يتطلب الأمر أن تتغير البنية المنطقية (أي المكزّنات 
البرمجية) حتى تدعم الخدمات الموقعية. مثلاء إذا كان شخص يحمل جهاز 
المساعد الشخصی الرقمی (۶0۸) أو هاتفاً خلوياً يتجول به فى مبنى ويصدر منه 
أمرا لطباعة وثيقة» فإنه يتم إعادة توجيه الربط إلى مشغْل أقرب طابعة ديناميكياً. 

إن الربط المحدد بالموقع ما هو إلا حالة من حالات الربط المحددة 
بالسياق النظري. أما في حالة فهم المحيط» فقد يتم توفْر معلومات السياق 
بواسطة آجهزة تحسس (مجسات). مثال على ذلك مجس الضوء الخارجي الذي 
قد يستشعر وجود ضوء الشمس. قد يتم ربط طلب توفير ضوء أكثر في الغرفة 
بوحدة برمجية ترسل إشارة إلى مشغل ميكانيكي ليفتح ستائر النوافذ. على لحو 
معاكس» قد تتسبب العتمة في الخارج بربط طلب التحول إلى أجهزة الإنارة 
الكهربائية. وقد تأخذ أمثلة أخرى على الربط المحدد بالسياق فى الحسبان حالة 
المستخدم الذي يتفاعل مع المحيط الذي يعمل فيه النظام. ٠‏ 

هذا وقد تكون البرامج الجديدة ذات مستويات الأعمال المتقدمة عرضة 
لتغير المتطلبات باستمرار. 

ترتكز نماذج الأعمال الحديثة على فكرة المؤسسات المرتبطة بواسطة 
شبكات تعمل على توحيد السلوك المتبع ديناميكياً لتحقيق أهداف العمل. قد يتم 
دعم المؤسسات الموحدة التي تستهدف تحقيق أهدافها بواسطة تركيبات برمجية 
على مستوى معلومات النظام. في مثل هذه الحال»ء يتكون تركيب البرمجية 
الموزع من عناصر تديرها مؤسسات مختلفة. تكشف كل مؤسسة - على جدة- 
عن جزء من المعلومات الخاص بها مما قد يكون مفيداً لاستخدامات المؤسسات 
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الأخرى» وفى الوقت ذاته» تستفيد من الخدمات التى تعرضها المؤسسات 
الأخرى. قد تتغير الروابط بين الخدمات المطلوبة والخدمات المعروضة ديناميكياً. 

يتطلب التحول إلى هذه الحالات وجود آليات تركيب جديدة للبرمجيات 
ومستويات جديدة من استقلالية سلوك النظم؛ بحيث تكون قادرة على التكيف 
مع التغيرات عن طريق إعادة تنظيم بنيتها الداخلية. يتضمن ذلك قدرة آليات 
التركيب على التعافي الذاتي» بشكل أكثر تعميماًء يجب أن تكون مرتكزة على 
مراقبة الجودة الشاملة للخدمة لتكون في أمثل حالء وقد يتغير ذلك مع الوقت 


يشرح ما تبقى من هذا القسم بعض الأمثلة على آليات التركيب التي تهدف 
إلى تحقيق درجة عالية من التقارن والدينامية لتتعامل مع متطلبات العالم المفتوح. 


1- 5 - 1 حيز التنسيق الشامل 


قد يستخدم وسيط لتوفير حيّز تنسيق شامل )6٥8(‏ (الشكل 41)ء تتفاعل 
من خلاله المكرّنات مع غيرهاء ويتم تنسيق سلوكها بطريقة منفصلة. يتصرف حيّز 
التنسيق الشامل على آنه وسيط. قد ينتج من كل مكوّن مشترك في الهيكلية بيانات عن 
تشارك محتمل مع مكونات آخرى. هذا ولا تتفاعل المكوّنات مع بعضها البعض 
بشكل مباشر للتنسيق وتبادل البيانات» بل يتم ذلك من خلال حيّز التنسيق الشامل 
الوسيط. بناء على ذلك لا يتوفر لدى المكونات المتتجة للبيانات أي معرفة صريحة 
عن العملاء المستهدفين ولا يكون لها ارتباط مباشر مع غيرها من المكونات. 
يتصرف الوسيط كواسطة بين المكوّنات المنتجة للبيانات ومستخدمي هذه البيانات. 

ثمة نوعان من الهيكليات القائمة على حيّز التنسيق الشامل : هيكليات من 
نوع نشر - اشتراك (عطاإوطاںu؟-طوناا٥)‏ وهيكليات من نوع حيّز - قائمة 
مکونات (مھ۵-5pاصن٣).‏ يتيح هذان النوعان للنظام أن یکون دینامیكیاً حیٹث 
إن المكوّنات قد تتحرك جيئة وذهاباً من دون أن تتطلب إعادة تهيئة النظام أو 
إجراء تغييرات من شأنها التأثير في المكرّنات التي أصحبت جزءً من الهيكلية. 
يكون التواصل في هذه الحالة غير متزامن إذ إن المكونات المنتجة للبيانات 
ترسل بياناتها إلى الوسيط وتستمر في تنفيذها من دون انتظار معالجتها بواسطة 
المستخدم المستهدف. 

نظم نشر - اشتراك (eطbنeطاu-طوناub)‏ : تدعم نظم نشر - اشتراك°2 
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حيّز التنسيق الشامل حيث إن المكوناث قد تعمل على نشر وقائع معيّنة يتم 
إرسالها إلى جميع المكونات التي أرسلت معلنة اهتمامها بهذه الوقائع سن خلال 
تقديم اشتراك. يوفر الوسيط تسهيلات لهذه المكوّناث لتسجيل اهتمامها بوقائع 
ععينة من خلال الاشتراك» كما پرسل الوسيط إشعارات عندما يتم إنشاء الوقائم 
الثي تهثم بها تلك المكوّناث. يعمل حيّز الثنسيق الشامل هنا كمحول للوقائم» 
وهو في هذه الحالة عيارة عن وسيلة عامة منطقياًء بيد أنه فد يثم تطبيقها كبنية 
تحتية لوسيط موزع بالكامل. ثمة أمثلة عديدة على نظم نشر - اشتراك؛ ذكرت في 
المواد** ٠‏ . ومن هذه النظم ما هو منتجات صناعية؛ ومنها ما هو نمافج 
بحث تثیح اسشخدام خصائص مثقدمة. بعض هذه النظم عبارة عن محول مرکزي 
وبعضها عبارة عن محول موزع. قد تختلف هذه النظم من الناحية الوظيفية» ومن 
ناحية جودة الخدمة التي تدعمها. فمن الناحية الوظيفيةء قد تختلف هله النظم في 
أنواع الوقائع التي تُنشتها وفي طريقة تحديد الاشتراكات. مثلاء من الممكن 
الشمييز بين لظم نشر - اشتراك المبنية على المحتوى وتلك التي تكون مبنية على 
الموضوع. في الحالة السابقةء الواقعة هي عبارة عن كائن ذي خصائص معيّنة 
يطلب الاششراك فيها. مثلاء تقد تكون الواقعة عبارة عن إشارة عن توفر رحلة 
طيران جديدة بين مديتني ميلانو وشيكاغو تبدأ من تاريخ معيَّن (مثلاً في الأول من 
كانون الأول) وبأجرة سفر معيّن (مثلاً 400 يورو). قد يحدد الاشتراك حالة اهتمام 
بمعلومات رحلات الطيران بين مدينتي مدريد ودبلن مثلاً وبأجرة مخفضة (أقل 
من 70 يورو). في نظم نشر - اشتراك المبنية على الموضوع» تكون الوقائع عبارة 
عن كياناتث مفردة. على سبيل المثال» يشم إنشاء الواقعة بواسطة إحدى شركات 
الطيران (مثلاً الإيطالية للطيران) عندما بعلن عن وجود رحلة طيران معينة. 


الشكل (1- 4) : حيز الشسيق الشامل 


مثال على ذلك» قد يكون لديتا الوقائع ٥لإيطالية»‏ أو «المتحدة» أو 
#الأوروبيةا. ولا تحمل هله الوقائم في هذه الحالة آي قیم. 

نظم حيّز ‏ قائمة مکونات (a0eم5-ماماا):‏ تدعم حيّز - قائمة مكونات 
)Space-eاupا)‏ العنسیق من خلال مستودع دائم : يوفر حيّز التنسيق الشامل 
خصائص تخزين واستعادة البيانات الدائمة. أما أول طرق التنسيق هذه فكان“ 
(هه«نا)". تدعم طريقة ليندا البيانات الدائمة على هيثة قائمة مرتبة من 
المكونات. وقد تكون قوائم المكونات المرتبة مكتوبة في حيَّز سلسلة 
المكونات؛ كما يمكن قراءتها (بطريقة لا تسبب تدميرها) وحذفها. تحدد 
عملیات القراءة والحذف قائمة مکونات من خلال قالب يستخدم لا ختیار قائمة 
المكرّنات من خلال مطابقة الأنماط. إذا حدد إجراء المطابقة أكثر من قائمة 
مكؤنات واحدة» يتم اختيار واحدة بطريقة غير حتمية. إذا لم يجد مطابقةء» يبقى 
المكوّن الذي أصدر آمر القراءة أو الحذف في حالة تعليق إلى أن يتم إدخال 
قائمة مكونات مطابقة في حيز قوائم المكؤّنات. 

هناك العديد من الفروقات في منهجية ليندا (ة1«0ا) الأصلية التي تم 
تنفيذها من قبل الوسيط المعتمد على نظم حيّز - قائمة مكزّنات ك 
(eممpوو«و)‏ . كما إن هناك تطبيقات مختلفة ملائمة أكثر لمتطلبات النظم 
الموزعة المتغيرة المكان ك (عصنا) , 


ثمة أهداف مشابهة لنظم حيّز - قائمة مكوّنات ونظم نشر - اشتراك» تهدف 
جميعها إلى توفير دعم مرن لهيكليات البرمجيات الديناميكية. بيد آن نظم نشر - 
اشتراك أقل أهمية: فقد تضاف صفة الديمومة كخدمة لكنها لا تكون مدعومة 
مباشرة كخاصية أصلية. 

1- 5 - 2 الهيكليات خدمية التوجه 

يدعم حيّز التنسيق الشامل التقارن والديناميكية عن طريق إلغاء الروابط 
المباشرة بين مصادر الرسائل ووجهاتها المستهدفة. تحقق الهيكليات خدمية 
التوجه (804) الأهداف نفسها عن طريق توفير تسهيلات تتيح للمكوّنات 
الإعلان عن توافرها وعن الوظائف التي تؤديهاء وتدعم اكتشاف مكؤنات تستطيع 
تنفيذ الوظائف المطاوبة. حالما يتم اكتشاف هذه المكؤنات» يمكن استخدام 


. <htftp:/netlib2.cs,utk.edu/pvmn3/book/node16.html > (#) 
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المكوّن عن بعد من خلال الربط المباشر. من حيث المبدأًء يمكن إجراء عملياث 
السجيل والاكتشاف والريط بطريقة ديناميكية في أثناء فثرة التنفي. 

تتكون الهيكلياث خدمية التوجه أساسياً من ثلاثة أنواع من المكوّنات 
(الشكل 5-1): مسشهلمك الخدمة» ومزود الخدمةء ووسيط الخدمة. أما مزود 
الخدمة فهو من بقدم الخدمة. والخدمة توصف من خلال خصائصها (رقد 
نفترض أنها تتكون من الوصف البيني تقريباً). بعلن المزود عن توفر الخدمة 
للوسيط الذي يقوم بدوره بعمل رابط للخدمة ويخرله في الواجهة. أما 
مرفقاً بمواصفة الخدمة التي يرغب في الحصول عليها. يقوم الوسيط بالاستعلام 
عن الخدمة» ويبحصل مرة آخرى على رابط بصله بالمزود. 


Servıce 
2) query Broker 
3) service 
Service 
Consumer 


1} advertise 


Service 
Producer 
4) Invokê 


الشكل (5-1): تصميم باتجاه تحقيق خدمة 


reference 


من هذه النقطةء يسشخدم المستهلك العمليات التي يعرضها المزود عن 
طرق التواصل المباشر معه. توفر الهيكليات خدمية التوجه حلا جيداً في حالات 
طلب تفاعلات معقدة بين عناصر مقترنة بعض الشيء والمتطابات التي قد پجري 
علیها تغيير» وعلیه پتطلب الأمر إعادة تنظيم مستمر وسريم للنظام. تقد ذكرنا 
سابقاً مثالا على التطبيقات المتنقلة في كل مكان» حيث يمكن تنفيذ هرحلة 
الاكتشاف ديناميكياً لتحديد التسهيلات المحلية المتاحة لربطهاء عند تغير الموقع 
الفيزيائي في أثناء التنفيذ. كما ذكرنا حالة عن نظم المعلومات المستخدمة في 
مؤسساث الأعمال المرتبطة بشيكات محوسبة - وهي اتحاداث الأعمال الديناميكية 
المتشكلة للاستجاية لفرص الأعمال المتغيرة. في هذه الحالة» تصدر كل مؤسسة 
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مشتركة في الاأتحاد بعض الوظائف التي تمنح وصولية مسيطر عليها للبرنامج 
الداخلي. بدوره» قد يستخدم البرنامج الداخلي الخدمات التي تقدمها برامج 
أخرى والاختيار بين عدة مزودين ممن يوفرون الخدمات نفسهاء بناءَ على بعض 
الأفكار الواضحة عن جودة الخدمة المطلوبة والمقدمة. تتوفر العديد من الحلول 
الوسيطة التي تطبق الهيكليات خدمية التوجه - على سبيل المثال»ء تقنية شبكة“ 
IND‏ أو 0865) 3 . على مستوی مؤ ؤسسة الأعمال»ء نشأت خدمات 
الويب“» ومجموعة الحلول القياسية التي ترافقها كطريقة واعدة» ليس في 
مجال البحث فحسب» بل بين الممارسين أيضاً. ٠‏ 


تعرّف “)18M(‏ خدمات الويب على أنها سلالة جديدة من تطبيقات ويب. 
وهي محتواة في ذاتها وموصوفة بذاتهاء كما إنها عبارة عن وحدات تطبيقية يمكن 
نشرها وتحديد مكان خاص بها واستدعاؤها من خلال الويب. تنفذ خدمات 
الويب وظائف معيّنة يمكن آن تكون أي شيء تتراوح من الطلبات البسيطة إلى 
عمليات الأعمال المعقدة. . . حالما يتم نشر إحدى خدمات الويب» يمكن أن 
تكتشفها التطبيقات الأخرى (وخدمات ويب أخرى) وتستدعيها. . . توفر تقنية 
خدمات الويب فائدة عظيمة تفوق التقنيات ذات التوجة الخدمى الأخرى ذلك 
آنها تهدف إلى تسهيل العمليات الواجهة بين البرامج المختلفة. ` 


يفيد ذلك بشكل خاص في البيئات المفتوحة» حيث يكون من المستحيل 
إجبار جميع المشاركين على تبني تكنولوجيا محددة لتطوير أنظمتهم. تتكون 
تقنية خدمات الويب من مجموعة من المعايير التي تحدد بروتوكولات الاتصال 
والواجهات التي ڌ تستوردها الخدمة من دوك فرض قيود على التنفيذ الداخلي 
للخدمات. أما الأمر العكسي» فإن الحلول الأخرى - ک (71۸۲)» فتعتمد علی 
لغة البرمجة جافا بهدف التواصل وتنفيذ الخدمات. تتيح التوافقية تكاملاً انسيابياً 


لحلول خدمات الويب المطورة من قبل مژسسات مختلفة. يعتمد التواصل بين 


(a)‏ هي هيكلية خاصة بالشركات لبثاء النظم الموزعة على هينة خدمات خاصة بالوحدات المتشاركة. 
طورتها في الأساس شركة (سد8)» حيث أصدرعما كإصدار تجاري. تم نقل )71٨9‏ بعد ذلك لشر ك (0طعهو) 
تحت الاسم )Re(‏ . توفر 71۸5) تسهيلات للتعامل مع بعض الأفكار الخاطتة حول نظم الحوسبة الموزعة 
ومشكلات تطور النظم والمرونة وأمن النظم ومكوناتما (المترجم). 

(#«) إطار العمل (0861) هو نظام وحدة وبرنامج خدمي يستخدم في لغة البرمجة (#«٠آ)‏ الذي يثفدذ 
وحدة مكونات ديئاميكية وكاعلة. يمكن تركيب التطبيقات والكونات عن بعد ومن ثم بدئه وتحديثه وإعادة 
تركيبه من دون الحاجة إلى إعادة تشغيل الجهاز (المترجم). 
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خدمات الويب على بروتوكول وصولية الكائن البسيطة [804۶] " الذي يصف 
بناء الرسالة النصية التي يمكن تبادلها على هيثة استدعاءات للوظيفة. يعتمد هذا 
البروتوكول على لغة الترميز القابلة للامتداد (1×)» ويتم تنفيذه من خلال 
بروتوكول تقل النصوص التشعبية (مطا)ط)» ما يحد من التدخل في نظم 
المعلومات لتوريد الخدمات. بعد اكتشاف توفر الخدمة وحالما يتم الربط بين 
مستهلك الخدمة ومزودهاء يتحقق التواصل عن طريق إرسال رسالة من خلال 
بروتوكول وصولية الكائن البسيطة. يمكن رؤية الخدمات على آنها تطور في 
المكرّنات الجاهزة للاستعمال. أما وظائف تطبيق الاستعمالات الممكنة وقيمتها 
بالنسبة إلى الآخرين فتتجه نحو التطوير اللامركزي» ذلك أن المؤسسة المسؤولة 
عن تطوير المكونات الجاهزة للاستخدام تختلف عن المؤسسات التي تستخدمها 
عموما. في كلتا الحالتين» ثمة منافع واضحة لذلك (تقليل فترة التطوير وزيادة 
الاعتمادية)ء» لكن هناك أيضاً مساوئ ممكنة لعمليات التطوير التي تتم بأكملها 
داخل المؤسسة نفسها (اعتمادها على أطراف أخرى لإحداث التطوير مستقبلا). 
الفرق الوحيد بين المكرنات الخدمية والمكونات الجاهزة للاستخدام هو أن 
الأخيرة تكون جزءاً من البرنامج ويتم تنفيذها في مجال ذلك البرنامج. آما 
الخدمات فهي ملك لمزود معن وهو مسؤول عن تنفيذها. تمثل آليات التركيب 
وجهاً آخر من أوجه الاختلاف» ففي حالة الخدمات» يمكن اختيار الأهداف 
الممكنة للربط وتنفيذ هذه الروابط ديناميكياً في أثناء فترة التنفيذ. 


أما الاختلاف الأكثر لفتاً فهو درجة التحكم والثقة. فالمكزنات الجاهزة 
للاستخدام لا يمكن ثغييرها بعد أن تصبح جزءاً من البرنامج إلى أن يقوم مالك 
البرنامج باستبدالها. من ناحية أخرى» تكون الخدمات ملكا للمزودين وهم من 
يتحکم بتطورها. وبناءَ على ذلك يمكن تغيير الخدمات لمنفعة المستخدمين. 


على الرغم من أن الخدمات أصبحت منهجاً عملياً في هيكليات النظم 
القابلة للتطورء لا يزال هتاك العديد من المشكلات التي يجب حلها قبل تطبيق 
هذه الخدمات في بيثات مفتوحة أو في الحالات التي يجب أن تلبّي فيها النظم 
متطابات الاعتمادية الصارمة. 


يبيّن القسم الآتي أهم التحديات التي يجب أن تحققها الهيكليات التي 
تدعم تراكيب البرمجيات الديناميكية بشكل عام» وعلى وجه الخصوص من قبل 
الهيكليات خدمية التوجه. 
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1- 6 التحديات والعمل المستقبل 

ناقشنا عدداً من المنهجيات المتبعة حالياً والمنهجيات الواعدة التي تدعم 
تركيب البرمجيات في العالم المفتوح. كما لاحظناء عندما نصبح الحلول ديناميكية 
أكثر وغير مركزية» حل العديد من المشكلات للوصول إلى الدرجة الضرورية من 
الاعتماد المطلوب عملياً. نحاول في هذا القسم تحديد أين تكمن المشكلات 
الرئيسة واتجاهات البحث الممكنة. بعض هذه المشكلات جديد» والعديد منها 
كان وما زال موجوداً لكنها تصبح أكثر صعوبة في الإعدادات الجديدة. 

التحدي الأول : فهم العالم الخارجي . كانت المتطلبات وما زالت مشكلة 
حاسمة بالنسبة إلى مهتدسى البرمجيات 3 * . إن اختيار وتحديد المتطلبات فى 
ظل الظروف دائمة التغيير أصبح أكثر صعوبة. في حالة النظم المتفشيةء يتطلب 
الأمر أن تكون الحلول ذات قابلية تكيّف عالية. مثلاًء يتطلب دعم كبار السن أو 
المعوقين جسدياً في بيوتهم تطوير حلول يمكن تكييفها وتخصيصها لاحتياجات 
معيّنة تتواءم مع مستخدميها. على مستوى الأعمالء يجب التقاط متطلبات 
الشركات الفيدرالية بطريقة ملائمة لدعم عملياتها الواجهة. من الأهمية بمكان 
تحدید ما يجب أن يتم عرضه للآخرين كخدمات وما يجب الاحتفاظ به 
وحمايته كملكية خاصة. إن التكامل السهل والديناميكي ضروري لالتقاط فرص 
الأعمال بسرعة. بالرغم من آن ذلك موضوع للبحث في المؤسسات التجاريةء 
إلا أنه يتوجب على مهندسي البرمجيات إدراك هذه التوجهات» إذ يجب أن 
يكونوا قادرين على التقاط المتطلبات الخاصة بالشركات الديناميكية وتشكيل 
الحلول الهيكلية بناء على ذلك. 

التحدي الثاني : دعم عمليات البرمجيات . تتسارع مؤسسات الأعمال باطراد 
في طريقة استجابتها لفرص الأعمال. هذا ويجب أن تتقدم عملية تطوير 
البرمجيات بالنهج السريع نفسه لتوفير الحلول بسرعة وذلك لتحقيق المزايا 
التنافسية وتقليل الوقت اللازم للتسويق. آما كيفية استجابة أساليب التطوير السريعة 
لمعايير الاعتمادية العالية التي قد تكون متطلبا للبرامج فلا تزال قضية مفتوحة. 
تصبح المشكلات أصعب لأن فرق التطوير أصبحت موزعة ومعقاة .249 , 
كيف يمكن تفعيل الممارسات المعيارية؟ ما هي محركات الإنتاجية الأساسية؟ 
كيف يمكن تعريف جودة العملية وكيف يمكن قياسها؟ 

التحدي الثالث: مواصفات الخدمة. إن التطور المستمر نحو الخدمات 
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التي يمكن تطويرها ثم نشرها لتستخدمها جهات آخرى تجعل من المهم توفير 
مواصفات لتلك الخدمة بحيث يستطيم المستخدموك فهمها. كانت مواصفات 
البرمجيات وما زالت موضع بحث نشط. يعود تاريخ الحاجة إلى مواصقات 
دقيقة يمكن أن تستخدمها برامج العملاء. المشكلة حاسمة في حالة 
الخدمات بسبب الفصل التام بين الموردين والمستخدمين وبسبب الحاجة إلى آن 
تكون المواصفات موثقة بطريقة أقوى وأكثر قابلية للتنفيذ. إذا كان الأمر متعاقداً 
عليه» يجب أن توفر المواصقات بياناً دقيقاً أكثر من مجرد تعريف صرف 
وتحوي لواجهة الاستخدام وأكثر تحديداً للوظائف. كما يجب أن ينص على 
الجودة التي تضمنها الخدمة. 


يجب أن تكون المواصفات قابلة للبحث. كما يجب أن يتم تحديدها من 
يجب أن يكون اشتقافق مواصفات إنشاء الخدمة الى تعرف مواصفاتها أمراً ممكناً. 


التحدي الرابع : البرمجة والتركيب. لقد قمنا بوصف النماذج المختلفة 
لتركيب الخدمة كنظم نشر - اشتراك ونظم حيّز - قائمة المكوّنات والهيكليات 
خدمية التوجه. يتراوح التنسيق بين المكوّنات من التراكيب المتسقة حيث يعمل 
مخطط سير العمل على تنسيق تنفيذ الخدمة حالما يتم اكتشافها وربطهاء إلى 
التراكيب المصممة كنمطى نشر - اشتراك وحيّز - قائمة مكرّتات» حيث يجب 
أن تتواءم الخدمات مع البروتوكول المشترك للرسائل المتبادلة والمضي قدماً 

يقة نظير - نظي ر“ . كيف يمكن لآليات التركيب المختلفة أن تتكامل 
وتندمج مع لغة البرمجة؟ كيف يمكن للغة البرمجة دعم مدى كامل من اليات 
الربط المرنة من فترة ما قبل التنفيذ الثابتة إلى الديناميكية الكاملة؟ كيف يمكن 
أن تتضمن سياسات الربط عمليات التفاوض واستراتيجيات إعادة الربط فى حال 
وجود تباين عن جودة الخدمة المستهدفة المعلن عنها؟ كيف يمكن أن تدعا 
سلوكيات الالتئام الذاتي أو التنظيم الذاتي من خلال التراكيب الملائمة؟ 


التحدي الخامس: الغقة والتحقق . إلى هنا تكون الخدمات قد طورت وتم 
تشغيلها في نطاقاتها الخاصة بها. لا يملك مستخدمو الخدمة أي سيطرة عليهاء كما 
إنهم لا يملكون صلاحية الوصول إلى باطتها. إذا كانت الخدمات مرتبطة في فترتي 
الترجمة والنشر فقط»› ولا يحدث عليها أي تغيير بعد ذلك فإنه يمكن أن تخضع 
التطبيقات لإجراءات التحقق التقليدية. لكن في حالة الربط الديناميكي» ونظراً إلى 
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آن تنفيذ الخدمة قد يتغير بطريقة غير مصرح بهاء فإن المنهجيات التقليدية تفشل. 
يجب أن تتم عملية التحقق في أثناء فترة التلفيذ. كما يجب أن تضمن 
عمليات مراقبة الخدمة المستم 5© إذا ما تم الكشف عن آي تباين عن جودة 
الخدمة المتوقعة وأن الإجراءات الملائمة قد اتخذت. بشكل عام» يجب آن 
پکون المستخدم قادرا على إيجاد طرق لضمان الاعتماد على الخدمة وجعلها 
آمنة كما تتطلبه المتطلبات. إن بثاء نظم آمنة وقابلة للاعتماد عليها من خدمات 


ذات موثوقية منخفضة هو تح كبير. 


التحدي السادس: الاتساق . في البيئات المغلقة» يكون التطبيق الصحيح في 
حالة متسقة دائماً مع البيئة التي يتواجد فيها. آما في البيثات المفتوحة» تتغيير 
البيثة مسببة تغيراً في البرمجيات وينتج من ذلك حالة عدم اتساق. هذا وقد أدرك 
العديد من الباحثين الحاجة إلى إدارة عدم الاتساق كإشكالية في السابى 1<5 . 
من الأهمية بمكان التعامل معها في حالة النظم المتطورة ديناميكياً. 

كانت تلك قائمة قصيرة تضمنت أهم التحديات التي يجب أن تكون جزءاً 
من أجندة البحث في مجالات هندسة البرمجيات. هذا ويجب أن لا يُنظر إلى 
هذه القائمة على أنها مضنيةء إذ إنها تركز فقط على بعض المشكلات التي 
تعمل علیھا مجموعتنا. يجب أن يستمر التطور في هذه المجالات وغيرها 
لتحسين جودة التطبيقات البرمجية في مجالات منبثقة جديدة. 
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الترڪيب في خطوط إنتاج البرمجيات 


کریستیان برو فر (Christian Prehofer)‏ 


جیلیس فان غر Jilles Yan Gurp)‏ 
جان بوش (1ط808c‏ ھل 


2 - 1 مقدّمة 


لقد حظيت خطوط إنتاج البرمجيات أو البرامج مؤخراً ببعض الاهتمام في 
مجالّي البحث والصناعة. انتقل العديد من الشركات من تطوير كل منتج من 
المنتجات البرمجية من الصفر إلى التركيز على القواسم المشتركة بين المنتجات 
المختلفة ووضع ذلك ضمن هيكلية المنتح وفي مجموعة مرثبطة من الموجودات 
التي يمكن إعادة استخدامها. عملية التطوير هذه هي عملية منطقية ذلك أن 
البرمجيات أصحبت تشكل جزءاً كبيراً من المنتجات وهي ما يحدد الخصائص 
المتافسة للمتتج في الأغلب؛ خصوصاً في صناعة النظم المضمنة. عند الانتقال من 
الأجزاء الهامشية إلى الأجزاء الكبرى في المنتج» يصبح الجهد الذي يجب بذله 
في تطوير البرمجيات أمراً مهماً أيضاًء إذ تبحث الصناعات عن طريق لزيادة إعادة 
استخدام البرمجيات المتواجدة أصلاً للحد من تطوير برمجيات الخاصة وزيادة 
جودة البرمجية. لقد آبدى عدد من المؤلفين خبرة في هيکليات خطوط الإنتاج. 
يعود تاريخ العمل في ذلك إلى آواخر عقد التسعينيات من القرن الماضي 7<" 
ثم تطور هذا القطاع من ذلك الحين باتجاهات جديدة لزيادة تطبيقات المفهوم. 


يلقي هذا الفصل الضوء على عدة تحديات نتجت من زيادة نطاق خطوط 
الإنتاج الناجحة وتطور مفاهيم جديدة لمنهجية تركيبية لخطوط إنعاج 
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البرمجيات” **“ . إضافة إلى ذلك نوقشت الآثار المترتبة على تطبيق هذه 
الإدارية وتلك المتعلقة بالعمليات. 


بالرغم من آن مفهوم منصات البرمجیات“ dl (Software Platforms)‏ 
الفهم نظرياًء إلا أنها تواجه تحديات مهمة عملياً. كما ناقشنا في المرجه» 
يقترض أن يلتقط نموذج المنصة الوظائف الأكثر عمومية والأقل تميزاً. مع 
ذلك لا تأخذ الوظائف المخصصة بالمنتج في الاعتبار الحدود بين المنصات 
والبرمجية التي تعمل ضمن تلك المنصة. إن التطور في النظم المضمنة قد ينتج 
من الآلات أو المعدات أو البرمجيات. أما التطور في المعدات والآلات فيؤثر 
في حزم البرمجيات. نظراً إلى أن واجهة الوصول للمعدات تكون ضمن برامج 
تشغيل الأجهزة في نهاية الحزمة بينما تكون البرامج المتأئرة وواجهات 
الاستخدام في أعلى الحزمة» يكون للتغيرات التي تطرأً على الآلات والمعدات 
تأثير شامل يسبب تغيراً في عدة مواقع أعلى أو أسفل حدود المنصة. 

ومن المصادر الأخرى التى تسبب تأئثيراً شاملا البرمجيات الخاصة. 
فالمتتجات الجديدة تتيح تحديد سيناريوهات استخدام جديدة تعرّف احتياجات 
جديدة للبرمجيات التي لا يمكن حصرها في عنصر واحد أو تطبيق واحد» بل 
لها تأثير في المستوى الهيكلي. من الأمثلة على ذلك إضافة خصائص الأمن 
وإضافة آطر عمل لواجهة استخدام أكثر تطوراً آو أطر العمل ذات الطبيعة 
الخدمية من خلال الويب. 

لقد نجحت عائلات المتتجات البرمجية فى حالات عديدة فى الشركات التى 
طبقت استخدامها. نظراً إلى ذلك النجاح» بدأت الشركات تطوير تلك البرمجيات 
لاتاحة استخدامها فى أمور تتعدى نطاقها الأؤّلى. يعزى سبب ذلك إما لأن الشركة 
ترغب في تحديد نطاق المنتجات حسب مدى تقاربها أو بسبب أن نجاح عائلات 
المتتجات المسبق قد أدى إلى وجود منتجات غير ذات علاقة ببعضها البعض»› 
ضمن عائلة واحدة. يسبّب ذلك وضعاً تصبح فيه عائلة المنتج البرمجي ضحية 
نجاحها الشخصي. فعندما يتسم نطاق المتطلبات وتتنوع المنتجات المدعومة»› 


(«) النضة في الحوسبة» هي البنية التحتية التي تسمح لبرنامج أو عتاد لأن يعمل. أهها: البنية المععارية 
للحاسوب ونظام التشغيل أو لغات البرمجة والمكتبات التشغيلية. إن كل حاسوب يتكون من معالج ونظام 
تشغيل اللذين يشكلان منضة التشغيل (المترجم). 
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تتسبب المنهجية ذات التوجة التكاملي الأصلية في العديد من المشكلات الخطيرة 
سواء كان ذلك في النواحي التقنية أو العمليات آو التنظيمية أو الأعمال. 


إن المنهجيةء ذات التوجه التكاملي» التقليدية المتبعة في خطوط إنتاج 
البرمجيات تخصص البحث والتطوير إلى مؤسسة تقوم بتسليم البرنامج كنظام 
برمجي متکامل ومُختبّر مرفقاً به جمیع ۸۴۲" التي یمکن استخدامها من قبل 
فرق العمل لاشتقاق المنتجات منها. إضافة إلى ذلك ثمة سيطرة هيكلية من 
الأعلى إلى الأسفل تقوم بها مؤسسة المنصة المركزية؛ بما في ذلك الإدارة 
المركزية للمتطلبات وخارطة طريق وتحكم تام بالمزايا وحالات التخيير 
واشتقاقات المنتج› إضافة إلى دمج وتکامل واختبار المنتج ومشتقاته. 

تعتبر منهجية المنصة الهيكلية شكلاً محسناً لمنهجية المنصة ذات التوجة 
التكامليء حيث تستخدم المنصة ويتم إضافة الوظائف الإضافية بحيث لا 
تعدل الوظائف الأساسية. يكون ذلك ملائماً فقط عندما تكون الوظائف الأساسية 
محددة جيداً وكافية لإنشاء المنتج بسرعة. ثانياً» ذلك لا يحد من مشاركة شيفرة 
البرمجة بين منتجات مختلفة ومشتقة خارج إطار البرنامج الأساسي. 


على الرغم من نجاح منهجية المنصة ذات التوجه التكاملي» إلا آنا نجادل 
في هذا الفصل في ما إذا كانت المنهجية تعاني بعض المحددات عندما يبدأ 
مجال المنتج بالتزايد. ومن ردود الأفعال الحدسية التي تبنتها الشركات اعتماد 
منهجية المنصة الهيكلية. على كل وكما ناقشنا في المرجع) تفشل هذه 
المنهجية علد وجود مدی واسع من المنتجات وتباین غير متوقع وفي حالة 
اشتقاقات المنتج؛ التي تتطلب تعديل أجزاء محددة في النظام وإعادة تصميمها. 

من التساؤلات الأساسية التي تطرح عن منهجية المنصة التقليدية هو أننا 
رأينا المؤسسات التي تعتمد المنصة ووحدات المنتج تواجه بعض العقبات في 
ما يخص التكامل. أولاء تظراً إلى أته يتم تنفيذ التكامل والاختبار في المنصة 


(#8) واجهة برمجة التطبيقات Programming Interac)‏ icationاApp)‏ واختصارها (4۴۳): هي چموعة 
من الروتيثات› وعیاکل البيانات و/ أو البروتوكولات التي تقدمها الكتبات و/ أو نظام تشفيل الخدمات لدعم 
بثاء البرامج. هناك توعان منها: يعتمد أحدها على لغة البرجة؛ إنه متاح فقط في لغة برجة معينةء ويقوم عل 
استخدام (×4ادر؟) وعثاصر هذه اللغة لحعله ملائماً للاستخدام في هذا السياق. والآخر مستقل عن اللغة وهذا 
يعئي أنه مكتوب بطريقة تتيح استخدامه في العديد من لغات البرجة. وهذا النمط مطلوب في أنواع الواجهات 
البرجية 40) المستخدمة في الخدمات غير المرتبطة بعملية معيّنة أو نظام تشغیل» وعادة ما یکون متاحاً کروتین 
منفصل. مثال عن النوع الثاني الموقع الذي عرض أماكن تواجد الطاعم في مكان ما (الترج). 
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عند مستوى المتتج» فقد يقود ذلك إلى تكلفة مرتفعة جداً لتنفيذ التكامل إذا 
كان تطاق خط إنتاج المنتج يتسع. إن الاعتماد الكبير على التكامل المتكرر 
يؤدي أيضاً إلى عدم القدرة على التوقع وعدم الكفاءة. ثائياًء يعرقل النطاق 
الراسع من وظائف المنصة مرونة إصدار مزايا جديدة إلى السوق ويزيد من 
الوقت اللازم لذلك. ثالثاًء يؤدي ذلك إلى فقدان المرونة وإلى دورات تطوير 
طويلة غير مقبولةء بسبب هشاشة المنصة الناتجة من عدم قدرتها على تجاوز 
نطاق المتطلبات الأساسي. أخيراً» لا يمكن لبرمجية تم تطويرها ضمن منتج 
معيّن أن يعاد استخدامها بطريقة ملائمة من قبل وحدات أخرى قبل أن يتم 
تضمنها فى إصدار لوحدة المنصة. ذلك أن وحدة المنصة لها دورة إصدار طويلة 
عادة بحیٹ يصعب إعادة استخدام البرمجية في مشل هذه المنهجية. بعبارة 
أخرى» علينا أن نتيح إمكانية المشاركة الأفقية بين المنتجات إضافة إلى 
المشاركة العمودية بين المنصة والمنتجات. 


ومن الحقائق المهمة الأخرى الأهمية المتزايدة للمكرّنات البرمجية ذات 
المصادر المتاحة للاستخدام والمكونات الجاهزة للاستخدام. آدى ذلك إلى 
تشوء عدد من التحديات التي تواجه المنهجيات التقليدية لأن هذه المكوّنات 
الجاهزة للاستخدام تتطلب منهجيات أكثر انفتاحاً لا تفترض تحكماً كاملا 
بالمزايا والخطط والأدوات. 


إن تطوير البرمجيات عامل منافسة وتمييز أساسي في العديد من المجالات 
كالأجهزة التي تعتبر جزءاً من البرمجيةء إذ إن هناك حاجة شديدة لمنهجية 
جديدة. نجادل هنا نتا نحتاج إلى نقلة نوعية جذرية في طريقة تصميم المنتجات 
البرمجية إذا كنا سنحقق تحسينا مهما في الإنتاجية ووقت الإصدار للسوق. 


يعرض هذه الفصل منهجية أكثر مرونة وأكثر انفتاحاً بالتفصيل وهي تعرف 
بمنهجية عائلة المنتج التركيبية؛ التي تتناول المسائل المذكورة سابقاً. الفكرة 
الأساسية للمنهجية التركيبية لخطوط إنتاج البرمجيات هي أن المنصة البرمجية 
لخط الإنتاج ليس بالحلول البرمجية المتكاملة بشكل كامل» بل هي عبارة عن 
مجموعة من المكوؤّنات واللإرشادات الهيكلية والمبادئ» إضافة إلى دعم الاختبار 
والتوثيق وسيناريوهات الاستخدام. بناء على بيئة المنصة المفتوحة والمرنةء يتم 
تكوين المنتجات بأكملها ودمجها واختبارها. حيث إن تكنولوجيا المكؤنات 
البرمجية تؤدي دوراً أكبر في هذه المنهجيةء نقترح في هذا القصل استخدام ما 
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يعرف ب «مقاطع الهيكلية؟» وهي عبارة عن مقاطع من الهيكلية الكاملة. هذه 
المقاطع الهيكلية تغطي أحد النظم الفرعية أو أكثر من الهيكلية. بهذه الطريقة 
يمكتنا ضمان أن يكون الاختبار والتكامل أكثر من مجرد اختبار على مستوى 
المكنات. وهذا مهم أيضاً في ما يتعلق بالمتطلبات غير الوظيفية خارج نطاق 
المكونات المفردة. هذه العملية موضحة في الشكل 2- 1 من الأمور الحاسمة 
هنا أن المقاطع الهيكلية لا تكون متكاملة كلياًء كما يجب أن تكون المكوّنات 
الخارجية التابعة واضحة تماماً, 


إن تبي منهجية عائلة المنتج التركيبية يسبب تحولاً متعمداً في مسؤوليات 
دمج واختبار المنتجات» حيث تنکون هذه المنتجات من المكرّنات آنقة الذكر. 
في تجربتنا هله تلائم هله المنهجية عائلات المنتج ذات النطاق الواسع 
والتطور السريع والابتکار المفتوح والمنافسة على مستوی المكوتات. 

لقد تم تقديم الحافز والخصائص الأساسية لمنهجية عائلات المنتع 
تحديداً فهرم مقط اليكلة اا ما سهم به هذا لقصل فهو ما پاي اڈ 
المتعلقة بتطویر لی رمیات ما ی ذل ال المتطلبات والعمليات والتنظيم والهيكلية 
والأدوات. 


أما بقية هذا الفصل فهي منظمة على النحو التالي : في القسم التاليء قدمنا 
المنهجية ذات التوجه التكاملي وناقشنا سلبياتها وعرضنا المنهج التركيبي كبديل. 
بعد ذلك» في القسم 2- 3» تم عرض مفهوم مقاطع الهيكاية كعتصر آساسي 
للمنهج التركيبي. 

يعرض القسم 2 - 4 مجموعة من تحديات البحث التي تواجه تطور ونضج 
المنهج التركيبي. 


2- 2 من المنهجية ذات التوجه التكاملي إلى المنهجية ذات التوجه التر كيبي 


يعرض هذا القصل بديلاً من المنهجية مركزية التكامل التقليدية ألا وهو 
عائلات المنتج. على كل قبل أن نناقش ذلك يجب أن يتم تحديد القضايا 
المتعلقة بمنهجية المنصة ذات التوجه التكاملي بوضوح أكثر. 
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تنظم عائلات المنتج من طريق الفصل التام بين تنظيم تصميم النطاق 
وتنظيمات المنتج. بوظف تنظيم تصميم النطاق دورة إصدار دورية يتم فيها 
إصدار معطيات النطاق بطريقة متكاملة ومختبرة» وتعرف دورة الإصدار هذه 
بمنصة الإطلاق (ص٣هاها۴)‏ . تستخدم تنظيمات المنتج منصة الإطلاق كأساس 
لإنشاء وتطوير المنتج من طريق توسعة المنصة بإضافة خصائص خاصة بالمنتج. 

يقسم تنظيم منصة الإطلاق حسب عدد فرق العمل» وفي أفضل الأحوالء 
يتم عكس هيكلية المنصة على عملية التقسيم. يقوم كل فريق من فرق العمل 
بتطوير المكوّن (أو مجموعة من المكونات المرتبطة) الذي يكون مسؤولاً عن 
التكامل في منصة الإطلاق وتسليم تنائج التكامل. على الرغم من أن العديد من 
الشركات قد بدأت تطبق عملية التكامل المستمر بحيث تكون المكوّنات متكاملة 
ومدمجة باستمرار في أثناء التطويرء إلا أنه عملياً يتم تنفيذ عمليات التحقق 
والمصادقة في الفترة التي تسبق إصدار منصة الإطلاق» وفي هذه المرحلة يتم 
العثور على العديد من الأخطاء الحرجة في النظام. 


مصائر المكونات 


ضمان جودة المكونات 


الشكل (1-2): الطريقة التركيبية 


تقوم المؤسسات المسؤولة عن التصميم بتسليم البرامج كنظم برمجية كبيرة 
متكاهلة ومُختبرة مع (4۴1) التي يمكن استخدامها من قبل فرق المنتج لاشتفاق 
المنتتجات منها. في حين تشكل البرامج مجموعة كبيرة من المزايا والصفات مع 
ها ناء فإن تکرار ! إصدار البرنامج يكون منخفضاً نسبياً مقارنةٌ بتکرار 
برامج المنتجات. بناءً على ذلك» تكون المؤسسات المسؤولة عن التصميم 
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واقعة تحت ضغط لتسليم أكبر قدر ممكن من المزايا والصفات خلال الإصدار. 
لذاء ثمة توجه إلى العمليات المختصرة خصوصا عمليات ضمان الجودة 
وخصوصاً في أثناء الفترة التي تقود إلى إصدار كبير» يتم تحويل جميع عمليات 
التحقق والمصادقة إلى فريق التكامل. وحيث إن المكوؤنات تفقد الجودة وفرق 
التكامل تواجه مشكلات التكامل ومشكلات أخرى على مستوى المكرّنات معا 
فإنه تظهر في أسوا الحالات دورة تكون فيها الأخطاء قد حددت من قبل فريق 
الاختبار الذي لا يكون لديه أي فكرة عن هيكلية النظام ويمكنهم تحديد 
الأعراض فقطء تستلم فرق المكونات تقارير عن الأخطاء الموجودة في النظام 
والتي قد تنشاً من أجزاء أخرى في النظام» وهنا يتوجب على فرق التكامل أن 
تعمل على إدارة التقارير الواردة من فرق الاختبار والتطوير عن المشكلات 
الحرجة في التظام» التي قد تودي إلى إصدارات جديدة من المكوّنات. 

على الرغم من آنه قد بنا العديد من التحديات التي تواجه هندسة 
البرمجيات التي ترتبط بمنصات البرمجيات» فقد آثبتت ت المنهجية نجاحاً كبيراً من 
حیثٹ تحقیر تحقیتق أکبر قدر من كقاءة البحث والتدريب والتكلفة المجدية التي تؤدي 
إلى منتج غني. 


وهکذاء أثبتت المنهجية ذاث التكامل المركزي نجاحها في نطاقها الأولى. 
على کلٌ» قد يتحول النجاح إلى فشل بسهولة عندما تقرر المؤسسة الاستمرار 
بناء على نجاح منصة البرمجية الأولي» وعلى التوسع الكبير في نطاق عائلة 
المنتج. قد تنتج توسعة النطاق عن قرار المؤسسة جلب المزيد من أصناف 
المتتج المتواجدة تحت مظلة المنصة أو بسبب قرار التنوع في المنتجات عندما 
تنخفص تكلفة إنشاء منتجات جديدة انخفاضا معقولا. فى هذه المرحلةء قمنا 
بتحديد عدد من الشركات التي توسع نطاق عائلة المنتج البرمجي من دون 
الحاجة إلى تعديل نمط العملية تعديلا جوهريا ما يؤدي إلى عدد من الشؤوك 
الأساسية والمشكلات المنطقية التي لا يمكن تجنبها. على كلٌ» ونظراً إلى 
النجاح المبكر الذي حققته المؤسسةء لم يتم تعريف المشكلات کاساس على 
نحو كاف» لكنها عرفت كتحديات تواجه التنفيذ» هذا ولا تتم التغيرات 
الأساسية على نمط العملية إلا بعد أن تواجه الشركة عواقب مالبة کي 


فی ما یأتی نعرض هذه المشکلات بالتفصیل» أولاً فى ما يختص نطاق 
المنصة» ومن ثم ما يختص بالانفتاح. 
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2 2 - 1 مشكلات الإفراط في نطاق العمل 

إذاء ما هى المشكلات التى تسبّب تغيّر نمط العملية التي كانت ناجحة فى 
البداية وتحوله إلى إشكالية؟ فى القائمة الآتية» نناقش المشكلات المتعلقة 
بالنطاق» التي يمكن للمرء ملاحظتها وإدراكها مباشرة. 

8 عدم توفر عمومية المكزنات: على الرغم من أن معظم المكزّنات كانت 
مفيدة لجميع المتتجات في النطاق الأولي لعائلة المنتج» إلا آن عدد 
المكوّنات المستخدمة فى مجموعة جزئية من المنتجات يزداد فى النطاق 
الممتد. 

© دمج وظائف غير مكتملة: كما ذكرنا في النقطة السابقة» في النطاق 
الأولي» تصبح معظم الوظائف مفيدة لمتتج واحد ذات صلة بمنتجات 
آخرى مع الزمن. بالتاليء هناك اتجاه لدمج الوظائف المختصه بمنتج 
معيّن مع منصة النظام مبكرآً» وقد يكون ذلك في بعض الأحيان قبل 
استخدام المنتج الأول. عندما يزيد طاق عائلة المنتج» تصبح مساوىء 
دمج الوظائف غير المحتملة أكثر وضوحاً. 

التطور البطيء للوظائف: عندما يزيد نطاق عائلة المتتج وعندما تعمل 
الشركة على المحافظة على المنهجية ذات التوجه التكاملى لتطوير 
الأجزاء المشتركة من البرمجية» يزيد زمن استجابة منصة النظام تجاوباً 
لطلبات إضافة وظائف للمزايا الحالية. 

© التبعيات الضمنية : في المنهجية ذات التوجه التكاملي» ثمة درجة عالية 
فی هله المرحلة» کہا تزید إنتاجية مطوّر النظام. 
عندما يتسع نطاق عائلة المنتج» يجب أن يتم تشكيل المكوّنات 
بتكوينات أكثر إبداعاً» وفجأة تصبح التبعيات الضمنية بين المكونات 
مشكلة حقيقية تعترض إنشاء منتجات جديدة. 

۵ عدم تجاوب تطوير منصة النظام : تكون دورة إصدار منصة النظام البطيئة 
محبطة خصوصا بالنسبة إلى فئات المنتج المبكرة في دورة النضوج. 
غالباً ما يكون إضافة خاصية جديدة إلى المنتج الجديد مطلوبة بسرعة. 

بأيّ حال» تتطلب الخاصية إجراء تغيرات في بعض مكونات منصة النظام. 
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بسبب کون دورة إصدار منصة التظام بطيئة يکون النظام غير قادر على 
الاستجابة لطلب فريق عمل تطوير المنتج. يكوت فريق العمل مستعداً لتنفيذ هذه 
المحتملة لجودة عمل فريق المنتج. 

عند تحليل هذه المشكلات مع النية لفهم الأسباب الكامنة وراءهاء يمكن 


تحديد الأسباب الاتية : 


6 التقليل من القواسم المشتركة الكاملة: قبل توسيع نطاق عائلة المنتج؛ 
تكون منصة النظام قد كونت جوهر وظائف المنتج. باي حال بزيادة 
النطاق» ستتنوع متطابات المنتجات» وبالتالي يقل مقدار الوظائف 
المتطلبة لجميع المنتجات سواء بشكل مطلق أو نسبي. بناء على ذلك» 
يقل عدد المكزنات المشتركة بين جميع المنتجات» ما يقلل أهمية 
منصة النظام المشتركة. 


© زيادة القواسم المشتركة جزئياً: تزداد الوظائف المشتركة بين بعض 
المنتجات أو الكثير منهاء لكن ليس كلهاء بشكل ملحوظ بزيادة 
النطاق. بناء على ذلك يزيد عدد المكزنات المشتركة بين ما بعض 
المنتجات أو ما بين معظمها. المنهجية النموذجية لهذا النموذج هي 
تبتي التسلسل الهرمي لعائلات المتتج. في هذه الحالة» تقوم مجموعات 
الأعمال أو فرق العمل المسؤولة عن فئات معيّنة من المنتج ببناء منصة 
فوق المنصة الشاملة للشركة. على الرغم من ذلك يخفف جزء من 
المشكلةء إلا أنه لا يوفر آئية فاعلة لمشاركة المكرّنات بين مجموعات 
الأعمال أو فرق العمل التي تعمل على تطوير المنتجات بفثات مختلفة 

# الهيكلية ذات التصميم المّفرط : بزيادة نطاق عائلة المنتج» تتسع أيضاً 
مجموعة الأعمال والصفات التقنية التى يجب أن تدعمها المنصة 
المشتركة. على الرغم من أنه لا يحتاج أي منتج دعماً لجميع الصفات» 
لكن يتطلب من هيكلية المتصة أن تدعمهاء وبناء على ذلك» فهي 
تحتاج إلى تصميم مفرط لتلبية احتياجات جميع المنتجات وفئات 
المنتج. لكن من شأن ذلك أن يعوق إمكانية التوسع ويزيد من الجهود 
اللازمة للصيانة. 
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8 الخصائص الشاملة : خصوصاً في النظم المضمتةء تفشل المزايا الجديدة 
في الالتزام بحدود منصة النظام. ففي حين أن النهج المعتاد هو أنه يتم 
التمييز بين الخصائص في شيفرة البرمجة الخاصة بالمنتج» إلا آنه غالباً 
ما تتطلب هذه الخصائص تغييرات فى المكرّنات المشتركة أيضاً. 
اعتماداً على المجال الذي تطور فيه المؤسسة منتجاتهاء فقد تتحول 
الفكرة العامة للمنصة التي تلتقط الوظائف المشتركة بين جميع 
المنتجات إلى وهم عندما يزيد نطاق عائلة المنتج 

® نضج فئات المنتج: تكون فئثات المنتج المختلفة التي تنتجها مؤسسة 
واحدة في مراحل مختلفة من دورة حياة البرمجة. التحدي هنا هو أنه 
اعتماداً على مدى نضج فئة المنتج» تختلف المتطلبات في المنصة 
المشتركة. على سبيل المثالء بالنسبة إلى فثات المنتج الناضجةء تكون 
الكلفة والموثوقية أهم العوامل» بينما بالنسبة إلى فثات المنتج في طور 
النضج» تكون غنى المزايا والزمن الذي يمكن توفير المنتج فيه في 
الأسواق هي العوامل الأهم. يجب توفر منصة مشتركة لتلبية متطلبات 
جمیع فثات المنتج الذي يقود بسهولة إلى توتر بين المنصة وفئات المنتج. 

2 2 - 2 مشكلات تتعلق بالمنهحية المغلفة 

من التحديات التي تواجه المنهجية ذات التوجه التكاملي التقليدية هو 

الأهمية المتزايدة لاستخدام البرمجيات التجارية والمكوّنات الجاهزة للاستخدام. 
الأمر الجوهري هو أن المنهجية ذات التوجه التكاملي تفترض وجود حكم قوي 
للمتطلبات والمزايا والخطط لكل من المنصة والمتتجات. يقود ذلك تحديداً إلى 
العديد من المشكلات : 

ه منصة أساسية غير مرنة: إذا أدمجت المنصة الأساسية مع برنامج 
خارجي کالبرمجیات التجارية › لن کون هناك سيطرة على خطة وعملية 
التطوير ودورات الإإصدار. يودي ذلك إلى وجود عدد من القيود ویصبح 
العثور على هيكاية تُلائم جميع المنتجات المشتقة تحدياً. 

# التطور: في حال أثر منتج واحد مشتق في توسيع المنصة عن طريق 
استخدام برمجية تجارية» فإنه يصعب تضمين هذه البرمجية فى منصة 
المنتج الرئيس لاحقاً. 
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عدم تطابق الأدوات والتنظيمات: توظف البرمجيات التجارية منهجيات 
تنظيمية وآدوات وممارسات للاختبار وضمان الجودة مختلفة»ء إذ 
يصعب دمجها في خطوط المنتج البرمجي كما ناقشنا في المرجه . 
والتتيجة هي أننا بحاجة إلى منهجية أكثر انفتاحاً لا تفترض سيطرة كاملة 
على المزايا والخطط والأدوات. تفترض المنهجية التركيبية» وكما هو وارد في 
الأقسام الآتيةء وجود بيئة عمل أكثر انفتاحاً وتلبي بسهولة أكثر إعدادات الإدارة 
غير المركزية والعمليات غير المتجانسة والأدوات. 


2 - 2 - 3 منهجية عائلة المنتج التركيبية 


إن الفكرة الأساسية للمنهجية التركيبية لخطوط إنتاج البرمجيات هو أن خط 
متكاملة وبيئة أدوات. يتم تولي دور المنصة المرجعية المتكاملة بواسطة مجموعة 
من الشرائح الهيكلية التي هي عبارة عن تركيبات متكاملة ومختبرة من أحد 
النظم الفرعية آو أكثر. يتضمن ذلك مكرنات محددة ذات تماسك عال وهو 
تكامل عمودي من مكرزنات ذات استقلالية عالية» ويمكن أن توسع لتشمل أطر 
عمل صغيرة. يجب أن تغطي مجموعة شرائح الهيكلية نطاق خط المنتج 
البرمجي كاملا وتمكين تكامل المتتج لاحقا. بينما يظهر مفهوم شرائح الهيكاية 
ممائلاً لعمل ذي علاقة في نمذجة الهيكاية "1 فإن فكرتنا العامة عن 
شريحة الهيكلية ترتكز على التكامل والاختبار» ونحن نركز أكثر على منهجية 
خط إنتاج البرمجية الكامل. 

على سبيل المثالء في الهاتف الخلوي» يمكن أن تكون مجموعة من 
تطبيقات الوسائط المتعددة التي تستخدم كاميرا ذاتية عبارة عن شريحة هيكلية. 
قد يتضمن ذلك العديد من متحكمات الكاميرات المتبادلة وتطبيقات التقاط 
الصور وعرضها والعديد من مكونات نظم التشغيل الخاصة بتخزين بيانات 
الوسائط واسترجاعها بسرعة. قد تختلف هله المكرّنات اعتماداً على درجة 
جودة الكاميرا وعدد الكاميرات في الهاتف. إضافة إلى ذلك» قد يعتمد دعم 
تظام التشغيل للكاميرات على الجودة («0ناساموه) والأداء المطلوب فى تخزين 
البيانات. هذا ويجب أيضاً تحديد الاعتمادية على مكوؤنات شرائح الهيكلية 
الأخرى. في هذا المثال» قد يكون تطبيق عرض الصور مرتبطاً مع تطبيق 
الرسائل وذلك لإرسال الرسائل مباشرة. إضافة إلى ذلك» قد يعتمد تطبيق 
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المؤتمرات المصورة بالفيديو على دعم الكاميرا لتسجيل المكالمات الفيديوية. 
ففي حين آن التبعيات يجب أن تكون موثقة ويمكن اختبارها باستخدام عيّنة من 
الشيفرة البرمجية»ء إلا أن إنشاء المنتج القعلي هو ما سيتم تكامله. يمكن قراءة 
المزيد من التفاصيل عن شرائح الهيكلية في الأقسام التالية. 

ملخص ذلك أن عائلة المنتج البرمجي التركيبية تتضمن ما يأتي : 

6 مجموعة من المكؤّنات المتماسكة التى تسهل التكامل. 

مخططات الهيكلية الشاملة والمبادئ التي تقود إلى تطوير المتتج لاحقاً. 

۵ شرائح الهيكلية التي تغطي نطاق خط إنتاج البرمجية الكامل وتجسد 

8 سيناريوهات الاختبار وبيثات الفحص الخاصة للمكونات وشرائح 

الهيكلية. 
# التوثيق التفصيلي عن الاعتمادية بين المكزنات وشرائح الهيكلية 
وتبعياتها والتركيبات الموصى بها. 

بنا على البيثة المرنة والمفتوحة» يتم تكوين منتجات كاملة ومتكاملة 
ومختبرة. 

إن باستطاعة منهجية عائلة المنتج التركيبية أن تتضمن منصة متكاملة 
لمنتجات أساسية معيّنة بدون دمج جميع مكوناتها. قد يخدم ذلك أيضاً منتجاً 

آما الفارق الرئيس فهو أن أغلب ما يشتق من ذلك المنتج هو عبارة عن 
تركيب من الأجزاء الموضحة في النقاط السابقة. 

في المنهجية ذات التوجه التكاملى» يجب أن تحل حزمة البرمجية 
المتكاملة جميع التبعيات والتقاطعات بين المكوّنات بواسطة الشيفرة البرمجية 
الفعلية. في هذه المنهجيةء يتم ذلك عن طريق دمج مجموعة من المكوؤّنات 
بواسطة شرائح هيكلية وعن طريق توثيق التبعيات الخارجية. إن توثيق التبعيات 
أمر في غاية الأهمية ويجب أن يتم كجزء أساسي في المنهجية التركيبية. مقارنة 
بالمنهجية التقليديةء فإتنا نقوم بجعل هله التبعيات واضحة ونترك الدمج الفعلى 
لعملية إنشاء المنتج. 
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آما الميزات الرئيسة والمواصفات التقنية لهذه المنهجية فهي : 

© هيكلية المنتج أكثر مروئة: لقد عرفت هيكليات المنتجات البرمجية 
بطريقة أكثر مرونة وليست مقيدة بهيكلية المنصة. وسبب ذلك عدم وجود 
هيكلية منصة مفروضة»ء على الرغم من أنه قد تتوفر هيكلية مرجعية تدعم 

© المسؤولية المحلية : تتقبل المكزنات المعادة الاستخدام التي قد تستخدم 
في إنشاء المنتج مستوى أكبر بكثير من المسؤولية المحلية. وهذه المسؤولية 
تعني آن كل مكوّن من المكزنات (آ) يستخدم واجهات استخدام محددة ومهيئة 
مسقا ومتطابة» (ب) يتحقق من أن جميع واجهات الاستخدام مرتبطة بشكل 
صحيح في فترتي التركيب والنشر» وأن المكؤن يمكن آن یوفر سیناریوهات 
الاستخدام أو المزايا (آو جزء منها) التي يعد بهاء (ج) يتضمن ذكاء كافيا 
ليضبط نفسه ديناميكياً لتتواءم مكؤنات الأجهزة الخادمة أو التابعة التي 
تعرض وظائف أقل من المتوقع أو تتطلب وظائف أكثر من المتوقع. 

© تقليا كافة الدمج : : تتم عملية دمج مكوّتات البرمجيات معادة الاستخدام 
والخاصة به بمنتج بعينه بواسطة ذلك المنتج› ولا تنفد أي عملیات دمج للمنصة. 
ونظراً إلى الذكاء المتنامي للمكوّنات. انخفضت الجهود المبذولة لتحقيق الدمج 
لتصبح جزءاً يسيراً من الجهد المبذول في المتطلبات. 

من الراضح أن هذه المنهجية تؤدي إلى وجود العديد من التحديات التي 

تهتم بجميع جوانب عملية تطوير البرمجيات. سنناقش هذه التحديات في القسم 
2 4. لکتنا سنناقش آولاً تأثیر هذه المنهجية في جوانب تطوير البرمجيات 
المختلفة. 


2 - 2 - 4 الفروقات الأساسية في المنهجية التركيبية 

حتى نشرح المنهجية التركيبية بشكل أدق وعلاقتها بالمنهجية ذات التوجه 
التكاملي» ناقشنا هاتين المنهجيتين من خمس وجهات نظر» نعتقد آنها ذات 
أهمية سائدة في سياق توسيع نطاق عائلات المتتج البرمجي» وهي : استراتيجية 
الأعمال» الهيكلية» المكؤنات» إنشاء المتتج والتطور. 


# استراتيجية الأعمال: غالبا ما يكون السبب الأصلي لتبني عائلات المنتح 
هو تقلیل نفقات التدريب والتطوير من خلال مشار كة معطيات البرمجية بين عدة 
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متتجات. على الرغم من أن ذلك لا يعني إهمال التدريب والتطوير في المنهجية 
التركيبية» بل يكو التركيز الأساسي على زيادة نطاف عائلة المنتج إلى الحد 
الأقصى. على الرغم من آن تكلفة التدريب والتطوير والزمن اللازم لإخراج 
المنتج إلى السوق عوامل ذات صلة في أي مؤسسة موجهة تكنولوجياأًء إلا أن 
الأساس المنطقي الأكثر أهمية للمنهجية ذات التوجه التركيبي هو إعطاء مطوّري 
المنتج مرونة وحرية أكشر› وبذا تصبح عملية إنشاء مجموعة أوسع من المنتجات 
أكثر سهولة. 


© الهيكلية: مبدئياًء يتم تحديد هيكلية عائلة المنتج كهيكلية بنيوية كاملة 
في ما يتعلق بالمكؤنات والروابط. تكون الهيكلية واحدة لجميع المنتجات أآما 
الاختلاف فيُحدد من خلال نقاط العباين في المكزنات. عند الانتقال إلى 
المنهجية التركيبية» يقل التركيز على العرض البنيوي للهيكاية بينما يزيد التركيز 
على القواعد الهيكلية المبطنة ما يضمن قابليتها للتركيب. كما ناقشنا مسبقاًء 
الفرق الأساسى بين هذه المنهجية والمنهجيات الأخرى فيتمثل في أن الهيكلية 
ليست موصوفة من حيث المكونات والروابطء بل من حيث الشرائح الهيكلية 


وقواعد التصميم وقیود التصميم. 


# المكونات: في أثناء المرحلة الأولى من عائلة المنتج البرمجي» يتم 
تنفيذ المكونات لهيكلية معيّنة محددة في جميع جوانبها أو معظمها. تتضمن 
المكونات نقاط تباين لتلبى الفروقات بين المنتجات المختافة فى العائلةء لكنها 
لا تمتد إلى ما وراء واجهات المكزنات على نحو ذي أهمية. أخيراً تنفْذ 
المكرّنات بطريقة تجعلها تعتمد على تنفيذ مكونات أخرى بدلا من الواجهات 
المحددة والضمنية. عندما يبحدث تطور نحو اعتماد المنهجية التركيبية» يبقى 
التركيز منصباً على المكونات. ومع ذلك» لم يتم تطوير هذه المكوّنات بطريقة 
مخصصة» بل أنها مقيدة في التنفيذ من قبل الهيكلية - أي من قبل مقاطع 
الهيكلية وقواعدها وقيودها التي نوقشت مسبقا. عند دمج كل مكون من 
المكوّنات فى شريحة هيكلية واحدة أو أكثر» يمكن ضمان قابلية التركيب لهذه 
الشرائح. ٠‏ 

# إنشاء المتتج : يفترض النموذج ذو التوجه التكاملي أن المنصة المدمجة 
مسبقاً التي تتضمن وظيقة عامة تكون متطلبة من جميع المتتجات أو معظمها من 
منتجات العائلة. يتم إنشاء المنتج من طريق استخدام منصة مدمجة مسبقا 
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كأساس» ومن ثم إضافة شيفرة برمجية مخصصة للمنتج فوق المنصة. وعلى 
الرغم من أن ذلك ليس ضرورياًء إلا أن الشركة تكون منظمة ضمن هذه 
الحدود. تعمل المنهجية جيداً عندما تكون عائلات المنتج ضيقة النطاق» لكن 
فعاليتها تكون أقل جودة عندما يكون نطاق عائلة المتتج واسعاً. في المنهجية 
التكاملية » يكون الهدف الضمني تسهيل اشتقاق مدى المنتجات الواسع الذي قد 
يحتاج إلى تشكيل المكونات بمدى واسع متساو من عمليات التهيئة. وعليه فإن 
إنشاء المنتج يتم باختيار معظم المكونات الملائمة وتهيئتها حسب متطلبات 
المنتج» وتطوير شيفرة البرمجة حيثما يازم ضبط التفاعل بين المكونات بالنسبة 
إلى متطلبات محددة للمنتج» وتطوير شيفرة برمجية خاصة بالمنتج فوق 
المكونات التي أعيد استخدامها. 


© التطور: في المنهجية ذات التوجه التكاملي» غالباً ما يكون هناك نزعة 
تفضيلية قوية نحو دمج مزايا ومتطلبات جديدة في المنصة التي سبق دمجها. 
وسبب ذلك آنه يجب إضافة مزايا جديدة قبل موعد الاستحقاق لجميع 
المنتجات» وبالتالي يكون الأسلوب الأكثر فعالية من حيث التكلفة هو تنفيذ 
ذلك مباشرة من دون تأجيل. كبديل» في حال كانت المنهجية المَثوي 
استخدامها تتطور من حيث الوظائف المخصصة للمنتج وتصبح سلعاً بمرور 
الوقت» ويتم دمجها في المنصة فإنها تضعف. في المنهجية التركيبية» تكون 
فرق العمل الخاصة بالمنتج وفرق العمل الخاصة بالمكونات مسؤولة عن تطور 
قاعدة الشيفرة البرمجية. تعمل فرق العمل الخاصة بالمتتج على زيادة المكوّنات 
المتوفرة بإضافة وظائف يتطابها المنتج خاصتهم» لكن يتم الحكم على مدى 
منفعتها وجدواها للمنتجات المستقبلية كذلك. هذا وقد تعمل فرق عمل المتتج 
على إنشاء مكرّنات جديدة للغرض نفسه. أما فرق العمل الخاصة بالمكرّنات» 
إن استخدمت» فتعنى أكثر بإضافة المزايا المتطلبة لعدد من المنتجات. مثال 
نموذجي على ذلك تنفيذ إصدار جديد لبروتوكول الاتصال. 


2 - 3 المكؤنات والشرائح الهيكلية 


في ما تقدم» ناقشنا المنهجية ذات التوجه التركيبي. في هذا القسم نتوسع 
في موضوع تطوير البرمجيات التركيبية بناء على المقومات الرئيسة والمكونات 
وشرائح الهيكلية. الطبيعة غير المركزية للتطوير التركيبي يجعل جمع أنماط 
تطوير عديدة ممكناً لأن المعطيات المهيأة يتم تطويرها بالضرورة بشكل مستقل. 
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2- 1-3 تقنية المكؤناث 


الفرق الأساسي بين التطوير ذي التوجه التكاملي والتطوير ذي التوجه 
التركيبي آن المنهجية التركيبية غير مركزية. أما المكونات التي يتم تكوينها فيتم 
تطويرها بشكل مستقل عن بعضها البعض» وعن المنتجات التي تستخدم هذه 
المكزنات فيها. أفضل تعريف للمكرن ملائم لهذا القصل قدمه كليمنس 
زايبيرسكي (5iإءمر52‏ و«عصها) في كتابه عن المكونات «المكون البرمجي هو 
وحدة من تركيب ذي واجهات محددة تعاقدياً وتبعيات واضحة السياق فقط, 
المكون البرمجي يمكن نشره بشكل مستقل ويكون عرضة للتركيب من قبل 
أطراف خار ج۰194 

بکلمات أخرى»› يتم تطوير المكوؤنات بصورة مستقلة» ومن ثم يتم دمجها 
وتكاملها من قبل طرق خارجي. نحن نفسر العبارة اوحدة من تركيب» بشكل 
واسع هتا. فحسب خبرتناء واعتماداً على المستوى النظري» تقسم النظم 
البرمجية الكبيرة جداً إلى مثات المكونات التي قد تكون بدورها كبيرة جداً. 

كما هو ملاحظ في المقدمة» النشاط الأساسي في المنهجية ذات التوجه 
التكاملي هو مرحلة الدمج والتكامل التي يتم خلالها تحديد الأخطاء 
والمشكلات الخطيرة وإصلاحها. تتيح المنهجية التكاملية في تطوير البرمجيات 
لمطور المنتجات والمكوتات تشغيلها بشكل مستقل. وبالتالي فهي منهجية قابلة 
للقياس تسمح لمزيد من المطؤرين: (آ) أن يعملوا معاً (عن طريق جعل عملهم 
غير مركزي) و(ب) بناء منتجات برمجية أكبر (عن طريق جمع مخرجاتها). 

لكن يصعب إنجاز عملية اختبار التكامل عند تطوير النظام بالطريقة 
التركيبية بسبب الأنماط العملية المستقلة لفرق تطوير المكونات والمنتج وغياب 
التخطيط المركزي وصتع القرار. 

طبعاًء يجب أن يقوم مطرر المنتج باختبار تهيثة المكوّنات المستخدمة في 
المتتج أو آي منتج آخر ذي علاقة. يجب أن لا يغير مطورو المنتج المكوّنات 
من حيث التهيئة (التلاعب بها جانباً باستخدام ۸۴1 الخاص بالتهيئة). كما 
يصعب على مطؤري المنتج أن يطلبوا من مطوري المكؤنات أن يصلحوا 
الأخطاء والأعطالء وأن ينفذوا المزايا أو يغيروها وغير ذلك. قد يكون ذلك 
صعباً لعدة أسباب : 
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6 يتوفر المكؤّن عن طريق مطزّري نظم من خارج الشركة (مثلاًء تعاقد 
جزئي أو مورد مكوّنات تجارية جاهزة للاستخدام أو مشروع تجاري). 
قد يكون لهؤلاء الأطراف بعض الالتزامات تجاه توفير وصيانة منتجاتهم 
(مثلا؛ المنتجات التي يحكمها عقد دعم) لكن قد لا يبدون اهتماما 
كبيراً بقضايا خاصة بالمتتج تظهر في آثناء دمج المتتج. 


# يتم تطوير المكوؤّن حسب خريطة الطريق الموضوعة له في اللإصدارات 
الكبيرة والصغيرة المخطط لها. آما القضايا التي لا تلائم خارطة الطريق 
تلك» فمن غير المرجح أن تأخل إهتماماً خلال فترة قريبة. 
# التغيرات المطلوبة التي تتعارض مع تلك التي يتطلبها مستخدمون 
آخرون قد تستخدم مكونات معيّنة في عدة منتجات. هذا وقد تكون 
المكؤنات الخارجية المستخدمة استخدمت في منتجات منافسة. عند 
مواجهة مثل هذه التعارضات» يجب أن يتم توفير الحل في المنتج بدلاً 
من حل مشكلة المكؤن. 
بناء على ذلك» يجب أن تكون المكونات المستخدمة في المنتج ثابتة 
ومختبرة جيداً قبل أن يصبح المنتج في مرحلة الدمج والتكامل. بمعثى آخرء 
يتضمن تبني المنهجية التركيبية وضع تركيز أكثر على اختبار المكوّن وجعل ذلك 
مسؤولية فرق تطوير المكون. 
في حال لم يتم توفير الوظيفة الأساسية لمتتج معيّن من قبل بيئة المكؤن 
بحيث لا يمكن إضافتها في شيفرة برمجية لاحقاًء فقد يتطلب الأمر إضافة 
مكرّن مشتق. يحدث ذلك في المنهجية التركيبية أكثر من غيرها إذ لا تكون 
خريطة طريق والمزايا متسقة جيداً. نحن ترى أن هذا الخيار ميزة إذ إنه يزيد 
المكوّن الداخلي. باستخدام المنهجية التركيبية للتطويرء فقد يتوقع أن تكون هذه 
المكونات قابلة للاستخدام في منتجات آخرى مطورة في الشركة نقسها. 


2 - 3 - 2 الشرائح الهيكلية والمكونات 


تعنون المنهجية التي شرحتاها في هذا القسم عملية فحص دمج وتكامل 
المكوّن باستخدام مفهوم الشرائح الهيكلية والدمج الجزئي. الشريحة الهيكلية لا 
تصف هيكلية المنتج كاملة» بل تصف المظاهر المرتبطة ببيئة المكوّن المتوقع 
أن يستخدم فيها. تعرّف المواصفة 1471 18۴۴ الهيكلية البرمجية على أنها 
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«التنظيم الأساسي لنظام منصوص عليه بمكوناته» والعلاقات التي تربط بين 
بعضها البعض والبيئة» والمبادئ التي توجه تصميمها وتطورها»*". في حالة 
التطوير التركيبي» فإنه ليس من المستحيل على مطوري المكون اعتبار جميع 
المنتجات التي تستخدم مكرناتهم. إضافة إلى ذلك» قد تحتوي هذه المنتجات 
على بعض العوامل المشتركة أكثر من حقيقة آنها تستخدم المكون. بمعنى آخرء 
بدلاً من التركيز على الهيكلية الكاملةء يجب أن يركز مطؤرو المكؤن على جزء 
منهاء ذلك الذي يرتبط مباشرة بالمكوّن. ونسمي ذلك الشريحة الهيكلية. 

الشريحة الهيكلية هي مجموعة من المكؤنات المقترنة بقوة» ينصح 
باستخدامها بهذا التركيب في المتتجات. في معظم الحالات» يمثل ذلك نظاما 
فرعيا للهيكلية. مثلاء في الهواتف النقالة» تكون الشريحة الهيكلية عبارة عن 
مجموعة من تطبيقات الوسائط المتعددة المعدة لكاميرا الهاتف وتتضمن 
متحكمات أو مجموعة من المكزنات التي تعمل على تشغيل ملفات الوسائط. 
كما تعرّف الشريحة الهيكلية تبعياتها الخارجية لمكرنات أخرى أو نظم فرعية 
أخرى. لا تكون الشريحة الهيكلية مكتملة بدون هذه التبعيات الخارجية ويجب 
أن تصف علاقتها مع هذه النظم الفرعية الخارجية. بمعنى آخر»ء تتضمن الشرائح 
الهيكلية افتراضات عن كيفية ارتباط التظم الفرعية الأخرى بها 

2 - 3 - 3 الشرائح الهيكلية واختبار التكامل 

كما ناقشنا مسبقاً» يشكل اختبار تكامل شرائح الهيكلية جزءاً أساسياً في 
المنهجية التركيبية. لهذاء إحدى آهم القضايا آنه يجب تحديد التبعيات للمكوّنات 
الخارجية. لاختبار مكوّن أو شريحة هيكيلة» يجب أن يور المطوّر بيئة تفي بهذه 
التبعيات. فباستخدام تهيئة الشريحة الهيكلية » يمكن تنفيذ تطبيقات بسيطة تختبر 
الجوانب المختلفة لوظيفة المكزن. في حال كان هتاك نية لاستخدام امتداد 
بإضافة مكرّن آخرء يكون إنشاء هذا الامتداد طريقة مفضلة للاختبار. 

يمكن تصنيف التبعيات للمكونات الخارجية في مجموعتین : 

© تبعيات الاستخدام : يعتمد المكوّن على غيره من المكونات. وقد يكون 
ذلك إما إصدارات محددة من المكرّنات أو كتطبيقات (4۴1) قياسية محددة إذ 
أصبح ذلك آمراً أكثر شيوعاً في عالم جافا (vaه[).‏ 

8 اإستخدام التبعياث: تشير هذه التبعيات إلى المكرنات الأخرى التي 
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تعتمد على هذا المكزّن أو التي يجب آن تعمل مع هذا المكوّن بشكل صحيبح. 

قد تكون العلاقات بين التبعيات مقترنة أيضاًء مثلاًء إن استخدام المكؤن 
4 يقتضي أيضاً استخدام المكرّن 8. يجب آن تكون مثل هذه العلاقات موثقة 
بالطبع. ثتم عملية اختبار التكامل طبيعياً كجزء من تطوير المنتج. كما أشرنا 
مسبقاً» يكون تحديد الأمور المتعلقة بالمكوّنات متأخراً جداً بشكل عام. وبناء 
عليه» يجب أن يتم اختبار التكامل مبكراً عند مستوى المكؤّن وشريحة الهيكلية. 
فبينما يكوك من المستحيل تحقيق منتجات كاملة كجزء من عملية اختبار 
المكوّن» يكون من المجدي توفير بيئة تستخدم للاختبار عينة من الاستخدامات 
المعروفة أو المتوقعة للمكوّن فى المنتجات الفعلية. 

® بالنسبة إلى تبعيات الاستخدامات (sعiعمصءلء‏ ممم ومولا)» قد تستخدم 
اختيارات من المكوّنات التى قد يستخدمها مطرّرو المنتجات. إذا كانت التوافقية 
أمراً مهماء فقد يتم إنشاء تهيثات متنوعة لشريحة الهيكلية بمكزّنات مختلفةء 
مشلا اختبر إصدارات متنوعة من المكوّن نفسه أو تطبيقات مختلفة ل ۸۴1 
نفسه. عندما يوسع المكوّن مكوناً آخر» يمكن وصف العلاقة بالمكوّن الموسع 
لعلاقة استخدام أيضاً. في هذه الحالةء يكون الاختيار سهلاً نظراً إلى كونه 
المكؤن الذي يتم توسعته هو دائماً نفسه. 

8 قد تون تبعيات الاستخدام )U sage Dependencies)‏ أکثر صعوبة. ففي 
بعض الحالات» قد يكون من الاستحالة بمكان الاختبار باستخدام تهيئة المنتج 
كاملة. عند تطوير إصدار جديد من المكوّن (تحديداء» عندما يتضمن ذلك تطوير 
التخيرات في واجهة برمجة التطبيقات 4۴1)» فمن غير المرجح أن تكون 
المكرنات الموجودة متوافقة. في هذه الحالةء لابد من محاكاة تبعيات 
الاستخدام باستخدام عمليات تنفيذ وهمية. إضافة إلى ذلك فى حالة استخدام 
المتتجات التجاريةء قد لا يكون المنتج البرمجي متوفراً بالكامل لمطوّر المكون. 


3-2 - 4 تبعيات المكوؤن 


في حين أن اختبار كافة المجموعات المتكونة من جميع التبعيات أمر 
مستحيل غموماًء إلا آنه يمكن أن نقرر مجموعات المكؤّنات المعروف لتا أنها 
ستعمل کما هو متوقع. يمكن توفير هذه المعلومات في وثائق النظام. 

تبدو هله الممارسة مألوفة في صتاعة البرمجيات. على سبيل المثال» تنص 
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ملا حظات الإإصدار ذي النسخة 1.1.0 Apache’s Jakarta Commons Logging) ja‏ 
)compPonent‏ على ما يلى : 


يتم تجميع كافة الأنراع (وعدوها٣)‏ المركزية باستخدام 1.2.x 72K‏ وقد يعمل 
ا على بعض #۴[ وعتإم8 1.1 المزادةء لكن يوصى أولئك الذين يرغبون فى 
تثفیذ هذه الأنواع على 1.18۴5 بتحميل المصلر وإنشاء تطبيقات مخصصة 
منه٤.‏ هذا مثال جيد على التبعية التي قد تعمل» لكن لا يوصى بها لأن مطوّري 
المكرّن لا يضمنونها في إجراءات الاختبار الخاصة بهم. تشير التوصية بوضوح 
إلى آنه لا يحبذ آن يستخدم المطوّرون 1.17۸۴ لكن يمكنهم ذلك إن رغبوا. 
وهذا مثال أيضاً حيث من الممكن أن يختار مطؤرو المنتج إنشاء إصداراتهم 
الخاصة من المكرّنات على مسؤوليتهم الخاصة. 


إن توثيق مجموعات العناصر التي تعمل والموصى بها أمر مألوف. هذا 
وسيشهد العديد من مزودي المكوّنات بأن برمجياتهم تعمل في مجموعات مع 
مكونات أخرى معيّنة» وستكون قادرة على توفير دعم واسع للمستخدمين إذا 
استخدموا المكزنات الموصى بها في مجموعات مع إصدارات المكزنات التي 
ينتجونها. إن هذه الشهادة ونموذج الدعم هما الأساس لمعظم مجموعات 
البرمجيات الجاهزة للاستخدام JBoss, MySQL S‏ . 


عملياً» يدفع ذلك المطورين (وبشدة) إلى تفضيل مكونات جودة الإصدار 
على إصدارات التطوير (إن توفرت) ولتلبية أي تبعیات لهذه المكونات باستخدام 
المكوّنات الموصى بها. إن قيام المطؤرين بذلك يتيح لهم الاعتماد على 
الاختبارات التى نفذها مطورو المكوّن مسبقاً والتركيز أكثر على اختبار تفاصيل 
المتتجء ٠‏ 

النتيجة الثانية هي آن ذلك يجعل من تحقيق التبعيات عملية قرار يتم 
إكمالها مبكراً في عملية تطوير المنتج. بشكل عام» في المنتج الجديدء تحقق 
معظم التبعيات في أثناء مرحلة تصميم هيكلية المنتج. هذا وقد تحدث بعض 
عمليات الترقية لإصدارات جديدة» لكن ليس من المرجح أن يرغب مدراء 
المنتج بالمخاطرة بعد آن يصبح جزءاً من عملية اختبار تكامل المكون. تختلف 
هاتان الممارستان عن المشاركة في تطوير المكونات والمنتجات في خط إنتاج 
البرمجيات. في أثناء مرحلة التكامل» يتم دمج المكونات باستمرار في إصدارات 
تطوير مكؤنات أخرى. بطريقة مماثلة» سينتهي الأمر بمطوّري المنتج باستخدام 
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اصدارات معدلة من المکونات ما يلغى بعض جهود اختبار التكامل التى نفذت 
مبكرآً. الممارسات المشار إليها أعلاه لا تشجع حدوث ذلك وتتيح لمطوري 
المنتح البثاء مستفيدين من الأساس المختبر جيدا. 


2 3 5 أمثلة 


الدمج والتكامل من دون بناء منتج كامل بناءَ على مكوناتها. هذا الأمر مهم 
لإنشاء مجموعات المكونات لأنها تتیح لمطوّري المنتج الاعتماد على اختبار 
التكامل الذي تم انجازه» بدلا من إجراء الاختبار بأنفسهم. 


ثمة مثال مقنع على ذلك وهو نظام توزيع لينوكس «هناءط*» وهو 
مجموعة من آلاف الحزم البرمجية مفتوحة المصدر"* والتي تعمل على 
لین وکس. إن هدف تأسیس صهناء( المعلن هو توفير توزيع تكاملي ثابت ومختبر 
بالكامل. آساسياً» يتكون معظم العمل من دمج هذا العدد الكبير من الحزم في 
التوزيع. ففي حين أن هناك بعض التطوير الخاص ب صفاطءط إلا أن معظم 
ذلك يتكون من البنية التحتية الخاصة ب «هاطء( والشيفرة البرمجية خاصتها. 
إضافة إلى ذلك يتم نشر التغذية الراجعة عن اختبار التكامل في الحزم التابعة 
مفتوحة المصدر»ء ويترافق ذلك في الأغلب مع الإصدارات الصخيرة الملحقة 
التي توفر حلولاً أمشكلات معيّنة (sعطءا۴)‏ . 


في المرجع' قڏمت بعض الاستراتيجيات المۇثرة في ما يتعلق بحجم 
التوزيع: بالقياس» وجد أن الإصدار 3.1 (ءعءة8 .4..) يتكون من 230 مليون 
سطر من الشيفرة البرمجية 10€ 5 . أما الإصدار 3.0 الذي صدر قبل ثلاث 
سنوات فقط من الإصدار 3.1 فقط وجد آنه يتكون من 105 مليوكن سطر من 


(#) هو نظام تشغيل متكامل» بدأ كإصدارة لجئو/ ليئوكس وأصبح اليوم أساساً للعديد من التوزيعات 
الأخرى من لينوكس» كما إنه يدعم أنوية نظم تشغيل غير لينوكس مل نواة هيرد» ونواة فري بي.إس.دي 
ضمن مشروع Debian GNUk Free BD‏ ویتم تطویر إصدارة 14× بئراة داعواه8 صمو علیه» ولکنها 
ليست جزءا من مشروع مواط بشكل رسمي» ودبيان هو مشروع غير ربحي على الإطلاق» وهو لا يثتحي 
لاي شركة؛ طوره الكثير من المبرجين من كافة أنحاء العالم (المترجم). 

(ee)‏ البرامج مفثوحة المصدر )O pen Source Software)‏ ھي البرامج ڄ التي يمكن تعديل شيفرتما البرجية 
وهي أكثر مرونة للمستخدم من البرامج الأخرى التي لا يمكن التعويل علبها» وعذه البرامج قد تكون مجانية أو 
بمقابل مادي (المترجم). 
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الشيفرة البرمجي» بيتما تكون الإصدار 2.1 (حسب المرجع) من 55 مليون 
سطر من الشيفرة البرمجية. وهذا يعني آن التوزيع قد تضاعف أربع مرات في 
حوالی خمس سنوات. حسب (ءاعءطW)‏ الذي طبق تظام C0٥00‏ على هذه 
المقاييس» يتوافق ذلك مع استشمارات بلغث قيمتها بلايين الدولارات ما تطلب 
آلاف مهتدسي البرمجيات للعمل معا في إطار زمني يوسع الزمن الفعلي 
المستغرق لتسليم هذه الإصدارات من صهناء( الذي تحكمه شركة صغيرة 
تمولها المنح المالية من القطاع الصناعي والأفراد. وهذا يعني آن منهجية 
التكامل التام غير ملائمة لنماذج K0٥K0M0‏ لتنتج نظاماً برمجياً مقارنة ب مطامط 
من حيث حجم الشيفرة البرمجية. 

من عمليات التطرير الممتعة التي نشآت في السنوات الأخيرة نشوء 
المشاريع مفتوحة المصدر» حيث يتم تطوير البرمجية بتعاون المطوؤرين الذين 
يعملون لدى شركات منافسة أو يحصلون على الدعم منها. ثمة دافع وراء هذا 
التوجهء آلا وهو المقاييس المذكورة أعلاه: فهي الطريقة الوحيدة الفاعلة من 
حيث التكلفة لتطوير حزم برمجية كبيرة بالاستعانة بالعديد من مهندسي 
البرمجيات في إطار زمني قصير. 


إذا لم يكن النظام يميز بين المنتجات الأساسيةء فإن استمرار العمل تحت 
مظلة ترخيص النظم مفتوحة المصادر قد يجعلها تميز بين المنتجات أكثر. إن 
توجه الشركات الطبيعي لحماية استشماراتها وملكياتها الفكرية يسبّب تعارضا 
مباشراً مع هذا الأمر ويعرضها لتحديات تنظيمية واستراتيجية. من الأمثلة الجيدة 
على الشركات التي تغلبت على هذه المعارضة شركة .18M‏ فمتذ خمس 
سنوات خلت» أصدرت الشركة نظام نا۴ لبيئات التطوير بلغة الجافا الذي 
يعمل ضمن ترخيص مفتوح المصدر. ثم حولوا عمليات تطوير وملكية المنتج 
إلى شركة مستقلة. أفادت الشركة من ذلك إفادة تفوق خسائر المبيعات التى 
تكبدتها الشركة من المنتج ١ه‏ سوال . أولاء العديد من المنافسين شاركوا في 
المشاريعم» ما آدى إلى نشوء بيئة تطوير تعتبر منصة تطوير معيارية في صناعة 
البرمجيات. نظراً إلى أن 18M‏ مرتبطة ارتباطاً وثيقاً بمنتج Eclipse‏ فإت ذلك 
يعني أن الشركات الأخرى قد فقدت القدرة على تمييز المنتجات» في حين أن 
قد اكتسب بعض تلك القدرة. 

إضافة إلى ذلك ففي حين تستمر 18۷ في استشثمار مصادر كثيرة في 
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م#منا8» فإن نسبة كبيرة من هذه الاستشمارات مشتركة مع المنافسين. إذاً إما أن 
يكونوا قد اقتطعوا بعض التكاليف أو أنهم استطاعوا التحسْن والابتكار بتكاليف 
أقل (مقارنة بإنجاز كل شيء في الشركة). كما أن بعض الأمور التي لم تكن 
۷ لتهتم لها فقد تم تمويلها من قبل جهات أخرى وهي الآن قيد الاستخدام 
من قبل عملاء 180. آخيراًء إن مساهمة 18۷ القوية في هذا المنتج تجعل من 
الشركة شريكاً مهما للمنتجات والخدمات ذاثت الصلة كالوسائط والمعدات 
والخدمات الاستشارية التي توفرها 18۷. يمكن الاطلاع على النقاشات 
والجدال حول هذا الموضوع بالرجوع “PCathedral and Bazaar Jjj‏ , 
2 - 4 معوقات بحثية لطريقة المعالحة التركيبية 

تمثل المنهجية التركيبية تطوراً محتملاً للشركات التي تستخدم منهجية خط 
هذا القسم» نهدف إلى توفير نظرة عامة عن هذه التحديات. 

2 - 4 - 1 إدارة المتطلبات اللامركزية 

إن نتيجة استخدام المنهجية التركيبية أن المتطلبات اللازمة للمنتجات 
المتكاملة يتم إدارتها بشكل منقصل عن المكوّنات المفردة التي يستخدمها 
النظام. 

في تطوير خط إنتاج البرمجيات ذات التوجه التكاملي» يتم إدارة 
المتطلبات بشكل مركزي. عند تطوير منتج جديد بناء على برمجية خط المنتج› 
يعرف مصمم المنتج المتطلبات الخاصة بذلك المنتج والمتطلبات التي يحققها 
خط إنتاج المنتج. إن تطور خط المنتج بدوره محكوم مركزياً وتوجهه المكوّنات 
المشتركة بين المنتجات ومتطلبات أخرى يعتقد آنها مفيدة للمنتجات المستقبلية. 
أما تطوير المكرّنات فردية فيكون محكوماً بالمتطلبات المدارة مركزياً. 

من سمات المنهجية التركيبية أنه لا توجد إدارة مركزية للمتطلبات 
والمزايا. یختار مطررو المنتج المكرنات وشرائح الهيكلية بتاء على كيفية 
دعمهم لمتطلبات المنتج› لكنهم قد يأخذون بالاعتبار عوامل أخرى» منها 
على سبيل المثال: 

ه القدرة على التأثير في متطلبات المكؤن: حتى لو لم تكن المتطلبات 


73 


متطابقة 100 فى المثة فإن القدرة على التأثير فى مسار المكوّن ستكون حاسمة. 


8 مسار المكون: قد يتضمن مسار المكوّن المعلن عتاصر ليست ذات 
صلة بالمنتج حالياًء لكنها قد تكون مستقبلاً. 

© الشهرة: قد يكون المكوّن قد أسس شهرة في ما يتعلق بخصائتص 
الجودة المهمة. 

ه الانفتاح: عند الإعلان عن الصناديق السود تتطلب العديد من 
المكزنات مستوى من الفهم لتصميم المكوتات الداخلية التي تجعل منها صناديق 
بيْضاً بكفاءة. يمكن القول إن هذا سبب مهم لعدم نجاح .٥018s‏ إضافة إلى 
البرمجيات الحالية. 

سيستخدم المكون الناجح في العديد من المنتجات التي قد يكون لديها 
بعض القواسم المشتركة» بغض النظر عن كونها تعتمد على المكوؤنات بطريقة 
آو بآاخری. 

قد تكون متطلبات المكون محكومة بواسطة عدد من العواملء منها: 

e‏ الحصول على تغذية راجعة عن التحسينات المحتملة من العملاء 
الحاليين الذين يستخدمون المكون. في حال وجود علاقات تجارية بين 
المنتج والمستهلك» فقد يكون هناك بعض المصطلحات التعاقدية 
(مثلاًء في سياق عقد الدعم). 

8 تحليل تسويقي لمتطلبات المنتج في المنتجات التي لا تستخدم المكون 
حالياً. إن تطوير المكون ليدعم هذه المتطلبات يمثل فرصة لنمو حصة 
المنتج في السوق. 

8 عرامل خارجية كالمعايير. قد تكون متطلبات المكرّن مرتكزة (جزئيا) 
على مواصفات معيارية أو واقعية. عند تطوير مثل هذه المواصفات»› 
یمکن أن یصبح دعم المواصفة المطوّرة متطاباً. 


(«) يستعمل تعبير الصندوق الأسود (<×80 عا8) في حالة عدم معرفة النموذج الداخلي (اعله للنظام 
(سعاءره) وطريقة العمل الداخلية » على عكس الصندوق الأبيض أو الأزجاجي (×80 دوعات) حيث نعرف كيف 
يتم تحويل المداخل إلى المخارج (المترجم). 
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8 عوامل داخليةء كتحسين عوامل الجودة التي تعتبر في غاية الأهمية 
بالنسبة إلى مطؤري المكون كإمكانية الصيانة. ومن العوامل الأخرى 
مدى اهتمام المطوّرين الشخصي في اكتشاف بدائل للتصميم أو العثور 
على مجالات تحسين صغيرة. 

نتج من هذه المنهجية منهجيةٌ أخرى ذات طبيعة «الأسفل - الأعلى»ء 

حيث إنه بدلا من أن تكون تابعة لمجموعة معيّنة من المنتجات (أي منهجية 
«الأعلى - الأسفل))ء هناك توجه لأن تكون العملية ذات مسار من الأسفل إلى 
الأعلى حيث يتم اختيار المكونات الأقل أو الأكثر استقلالية ويتم وضعها معاً 
لتحقق متطلبات المنتج. بهذه الطريقة» يتم حل التعارض المحتمل بين 
المكوّنات المطررة المستقلة عن طريق اختيار المكوّنات وعملية الدمج. 


2- 4 - 2 إدارة الحودة والهيكلية 

من ميزات المنهجية التركيبية عدم وجود هيكلية مركزية. بدلا من ذلكء 
هناك هيكلية خاصة بكل منتج وبكل شريحة هيكلية. وهذا يضع عددا من 
التحديات آمام البحث في ما يتعلق بتطبيق أساليب تقييم الجودة» كمثال» وهذا 
يفترض وجود هيكلية مدارة مركزياً وسيطرة كاملة على الموجودات التي 
تحكمها الهيكلية. 

إن الهدف من تطبيقق أساليب تقييم الجودة هو التحقق من مطابقة متطلبات 
الجودة المدارة مركزياً (وهذا غير متوفر في المنهجية التركيبية) ولتحسين جودة 
المنتج من طريق تحديد القضايا المتعلقة بالجودة. على كلٌء إن تنفيذ تقييم 
الهيكلية على مستوى المنتج يجعل الأمر منطقياً نسبياً نظراً إلى غياب التحكم 
بالمكونات المشكلة. 

8 نتيجة ذلك» يجب أن يتم تقييم الجودة والتحسينات عليها على مستوى 
المكوّن أو على مستوى الشريحة الهيكلية. على كلٌ» في ظل غياب 
إدارة متطلبات الجودة المركزية وغياب السيطرة على المكرّنات المستقلة 
والتابعة» فإن ذلك يعني آن ضمان جودة متطلبات النظام كقيود الزمن 
الحقيقي والمخرجات والأمن وغيرهاء من الصعوبة بمكان. يجب أن 
يتوقع مطؤرو المكؤنات متطلبات الجودة التي يتطابها العملاء 
المحتملون ويحولونها إلى مطلب لتحسين المكون. 
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8 من القضايا الأخرى» أن معظم أساليب تقييم الهيكلية تتطلب نظاماً 
متكاملا. في المنهجية التركيبية» يُفضل أخذ تأثيرها في الجودة في الاعتبار 
قبل أن يتم دمج المكزنات. قد تؤدي آي من المشكلات التي يتم تحديدها 
إلى تحسين في المكؤن؛ لكنها قد تؤدي أيضا إلى اختيار مكونات بديلة. 

الهدف الثاني من وجود هيكلية واضحة للبرمجية هو فرض نمط الهيكلية 

وقواعد التصميم. وسبب ذلك هو أن ذلك يضمن أن تكون مكرنات الهيكلية 
مناسبة لبعضها بعضاً. ثمة مشكلة تتعلتق بالمكونات الجاهزة للاستخدام التجارية 
وهي البحث عن مكرنات ذات واجهات متطابقة. إن غياب الهيكلية المحكومة 
مركزياً لا يعني عدم وجود قاعدة موجُهة للهيكلية. لكن بالضرورة أن المكونات 
التي ستستخدم مع بعضها بعضاً يجب أن تشترك في هيكلية. على الأقل يتطلب 
ذلك وجود مستوى معيّن من التوافقية. هذا ويمكن تخطي الفروقات الصغيرة 
باستخدام الشيفرة البرمجية. لكن إن القيام بكميات معيّنة من الشيفرة البرمجية 
ليس بالأمر المحدد عند إنشاء المنتجات. بناء على ذلك» تطرح التوافقية عدداً 
من التحديات الجديدة: 

® كيفية توثيق الخصائص الهيكلية للمكونات والشرائح الهيكلية. 

© كيفية تحسين هيكلية المنتج على النحو الأمثل بحيث تكون الأمثل 
للمكونات التي ستتكون منها. 

© كيفية تصميم المكونات بحيث لا تفرض العديد من القيود أيضاً. 

2 - 4 - 3 تكنولوجيا المكؤتات البرمجية 

تم تأييد البرمجة ذات التوجه المرتكز على المكونات وخدمات الويب 

اللاحقة باعتبارها خطوة مهمة نحو بثاء نظم برمجية كبيرة. وسبب ذلك 
بالدرجة الأولى هو توفير بنى تحتية معيارية للمكرنات مع واجهة برمجة 
تطبيقات ۸۴1 معرَفة جيداً إضافة إلى الخدمات ودعم التوافقية. وعلى الرغم من 


أن ذلك تطور كبيرء إلا آنه لم يوضح القضايا المتعلقة بالتغيير والهيكلية كما في 
خطوط المنتجات البرمجية. 


فى خطوط المنتجات البرمجية والعديد من الأدوات المستخدمة فى إدارة 
التهيئة› یتم إدارة التبعيات بين المكونات. فالتبعيات المدارة هى مكوّنات 
أساسية للمنهجية التركيبية. لكن» يشمل ذلك إدارة تبعيات الشيفرة البرمجية 
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التركيبية فقط _ مثلاء في ما يخص النسخات المختلفة وتوافقية واجهة برمجة 
illطlaıتٽ (Application Programming Interface - API)‏ . 


كما قد تتضمن معلومات هذه الأنظمة على تهيئثات مختبرة» ويمكن بالتالى 
أن تستخدم لوصف الشرائح الهيكلية. 

الأمر المشوق في هذا السياق هو العمل المعروض في المرجم““. فان 
آوميرينغ OmmerinE)‏ ص۷a)‏ هو المؤيد والنصیر لما يُسمى بتسكين خطوط 
المنتجات ويقدم تقنية المكزنات التي تدعم تلك الفكرة. إن منهجيته شبيهة جداً 
بمنهجيتنا لكنها تركز على المظاهر التقنية للمكزّنات أكثر من التركيز على 
المظاهر الأخرى التي ناقشناها في هذا الفصل. 

بالنسبة إلى الغرض من خطوط المنتجات البرمجية التركيبية » نحتاج إلى 
مكوّنات يمكن أن تعمل في سيناريوهات الاستخدام والبيئات غير المتوقعة والمفاجئة. 
وهذا يعني › مثلاًء إدراك وقوة للتبعيات والتفاعلات مع المكوّتات الأخرى. 

وبشكل أكثر تحديداًء التحديان الرئيسيان اللذان ناقشناهما هتا هما 
التبعيات الدلالية التي يجب أن يتم إدارتها بطريقة أكثر وضوحاً والثاني هو 
كون المكوّنات مصممة بطريقة أكثر قوة. 

إن التفاعل الدلالي («0نامة٣ءا٢!‏ ءنامو؟) بين المكرّنات يعني آنه یجب 
التكبْف مم سلوك المكوك عن تركيبه مع مکوّتات آخری. وهذا يتعدى التوافق 
النحوي (yاi Compa‏ ieاaeاSyn)‏ لواجهات برمجة التطبيقات وتم التحقق منه 
بتوسع في سياق البحث في تكامل المزايا“ . هذا وقد تكون هذه التفاعلات 
إيجابية أوسلبية : 

© يتطلب التفاعل الإيجابي إضافة وظائف إضافية. على سبيل المثالء إذا 
كان لدينا تطبيق للبريد الإلكتروني خاص بالهواتف المحمولة وتطبيق 
لعرض الصورء فیجچب أن يکون بالإمکان عرض الصور الواردة عبر 
البريد الإلكتروني. 

6 يتطلب التفاغل السلبي منا رفض إجازة بعض الحالات أو حذف الالتباس 
والغموض. عادة ما يتناقض مكرنان أو ميزتان في سلوكهما أو تتنافسان 
على الموارد المحدودة. مثلاًء وضع الهاتف النقال على وضعية السكون 
ينبغي ألا يعطل ساعة المنبه فيه. 
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في الواقع» تحدث بعض التبعيات عندما یتم جمم العديد من المكونات 
فقط ولا يمكن مراقبتها عندما يقتصر الأمر على ميزتين فقط في الوقت 
الواحد“ . قد تكون المشكلات المتعلقة بالمزايا السلبية المرتبطة بالتكامل 
صعبة» ولا يمكن تحديدها بسهولة في منهجية اختبار التكامل غير المركزي 
الموضحة سابقاً. 


2 4 - 4 العملية وقضايا التنظيم 


يشير المرجع“ إلى أن هناك العديد من الطرق المستخدمة لتنظيم خطوط 
المنتجات البرمجية. إن تبني المنهجية التركيبية يجعل من الممكن ومن 
الضروري التنظيم بأسلوب مختلف. فكما ناقشنا في آقسام سابقة» من 
الخصائص الأساسية للمنهجية التركيبية أن هناك إدارة أقل مركزية للمتطلبات 
والهيكلية والتنفيذ. أساسياًء يحدث التطوير والتطور للمكونات بطريقة غير 
مركزية. إن فصل تطوير المنتج عن تطوير المكون هو هدف صريح للمنهجية 
التركيبية لأنها تتيح اتخاذ القرارات التي تؤثر في المنتجات التي يجب آن تكون 
منفصلة عن اتخاذ قرارات تؤثر في المكرّنات. 


إن القيام بذلك في الشركة تفسها يؤدي إلى تناقض في إدراك آن للشركة 
أهدافاً وتوجهات ورؤية. إن جميع الأنشطة التي تقوم بها الشركة (بما في ذلك 
تطوير المكوّنات والمتتجات) تتبع هذه الرؤية الشاملة (آو يجب آن تتبع انطلاقاً 
من تلك الرؤية). وهذا يعني أن تطوير المنتجات غير مستقل عن تطوير 
المكرنات إطلاقاً. وبالتاليء فإن تقديم منهجية تركيبية في شركة تعمل على 
تطوير المنتجات ينطوي على عدد من التحديات : 
© كيفية التنظيم؛ إذ إن فرق تطوير المنتج لها حرية اختيار المكونات 
الخارجية أو بدء تطوير مكزّنات جديدة بدلا من استخدام المكزنات 
المطزرة داخلياً. إن قرارات الأعمال التي تتخذها فرق العمل بشأن عدم 
استخدام المكرّنات المطررة في الشركة نفسها له عواقب سلبية على 
فرق تطوير المكرنات. فقد لا تكون أفضل الحلول التقنية هي الأفضل 
بالنسبة إلى الشركة كلها. إن موازنة هذه الأمور هو التحدي الرئيس 
الذي يجب تحديده. 
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إن السماح لفرق تطوير المكوؤنات بالاضطلاع بمسؤولية المخططات 
والهيكليات الخاصة بالمكوّنات خاصتهم من شأنه أن يؤدي إلى وضع 
يتم فيه إنفاق الموارد على تطوير المزايا والمنافع التي لن تستخدم من 
قبل أي فريق من فرق تطوير المتتج. إن موازنة ابتكارات وأفكار فرق 
تطوير المنتج وفرق تطوير المكوتات أمر في غاية الأهمية للسيطرة على 
تكاليف التطوير كما هو مخطط له. 


من القضايا التي تبرز في أي شركة» عملية توزيع الموارد (المال 
والأشخاص والوقت وغيره) على وحدات العمل في الشركة. أساسياًء 
تتنافس فرق تطوير المنتج وفرق تطوير المكون على الموارد نقسها. 
لكن فرق تطوير المنتج هي وحدات العمل الوحيدة التي تساهم مباشرة 
فى إيرادات الشركة» وهذا يقود إلى انحياز تفضيلى لها. لذاء فإن تبتّى 
منهجية تركيبية يقتضي إنشاء سلسلة القيمة الداخلية أو آلية تسويق 


لتوزيع الموارد الداخلية. 


في حين آنه قد تستخدم المكونات من قبل فرق المنتج فقط» فقد 
تصبح المکونات نفسھا منتجات قد تهم شرکات تطویر برمجیات أخرى. 
وحيث إن هذا لا يتعارض مع المفاضلة بين المنتجات» إلا آنه يفضل 
في تسويق مثل هذه المكونات بصورة منفصلة عن بعضها بعضاًء أو قد 
یتم مشاركة عبء تطویرها مع شرکات أخری حتی لو كانت شركات 
منافسة. إن تحويل المكرّنات إلى منتجات داخلياً أو الاعتماد على 
مكزّنات ذات مصادر مفتوحة هو من الآثار الجانبية الطبيعية لتطبيق 
المنهجية التركيبية» لكن قد يقود ذلك أيضاً إلى إيجاد متطلبات جديدة 
غير معرفة في نطاق تطوير المنتج الأصلي. 


بالنسبة إلى هله التحديات التنظيمية› پچب تحقیق توازن حذر بین 


الاهتمامات المتضاربة لفرق تطوير المتتج وفرق تطوير المكؤنات والمهمة العامة 
للعمل. 


لكن» يجب ملاحظة أن هذا الأمر ينطبق على المنهجية غير التركيبية. إن 


سبب التحول من منهجية التطوير القائمة على خط المنتجات البرمجية إلى 
المنهجية التركيبية فهو أن الإدارة المركزية لهذه القرارات تصبح أصعب بنمو 
عملية التطوير في القياس› وان نطاق خط المنتحج البرمجي يصبح أوسع. 
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2 5 الملخص 

أوجدت عائلات المنتجات البرمجية اعتماداً واسعاً على صناعة النظم 
المدمجةء إضافة إلى مجالات أخرى. ونظراً إلى نجاحهاء تشهد عائلات المنتج 
في العديد من الشركات توسعاً في نطاق العائلة. لقد ناقشنا العديد من القضايا 
الأساسية التي يمكن آن تنشأ عن ذلك وعن آمور آخرى كالبرمجيات التجارية 
والبرمجيات الخارجية التي تكون خارج سيطرة المؤسسة. 

بالنسبة إلى عائلات المنتج التي تهدف في المقام الأول إلى تغطية مدى 
واسع من المنتجات» فقد اقترحنا مفهوم عائلات المنتج التركيبية. تعتمد هذه 
المنهجية على تنظيم غير مركزي يعطي عملية إنشاء المنتج مرونة ومسؤولية 
أكبر. كما إنها تعطي حرية لمطؤري مكرن المنتج الداخلي. بدلاً من دمج 
المنصة بالكامل» نعتمد على مفهوم شرائح الهيكلية الجديد لضمان التكامل 
والاختبار إلى ما بعد الاختبار على مستوى المكوتات. إضافة إلى ذلك بيّنا آن 
هذه المنهجية التركيبية يجب أن تتضمن جميع جوانب تطوير البرمجية لأضمان 
نجاحها. كما آننا حددنا العديد من تحديات البحث الرئيسة التي تعترض 
المتهجية الجديدة في ما يخص المتطلبات وإدارة الجودة وتقنيات المكؤنات 
البرمجية إضافة إلى العمايات وتقسيم المسؤوليات في المۋسسة. 

من الأمور التي تثير اهتمامنا في شركة نوكيا (aا٤ه۸)»‏ حيث ارتكزت 
عملية التطوير على المتهجيات ذات التوجه التكاملي» أن السلوك المتشعب 
والمتطلبات غير الوظيفية كفعالية أداء الجهاز واستهلاك الطاقة. لقد أثبت ذلك 
صعوبة المنهجية ذات التوجه التكاملي البالغة التي نعتمد عليها حالياً. 
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3 
تعليم أنماط التصميم 


پیرند بروغ (Bernd Brügge)‏ 
وتیمو وولف (1هW )|٣۵‏ 


3- 1 المقدمة 

في البرمجة كائنية التوجه» تكون آنماط التصميم عبارة عن قوالب يمكن 
أن يعاد استخدامها مرات عديدة لحل طائفة من المشكلات متكررة الحدوث” . 
یتکون نموذج التصميم من الاسم ووصف المشكلة والحل والنتائج. تنتمي 
أنماط التصميم إلى مهندسي البرمجيات المختصين بالمعرفة الأساسية ومصممي 
الهيكلية ومطوّري النظم كائنية التوجه وتوفر لغة مشتركة بين المساهمين في 
مشروع ٿطوير برمجي. 

يتضمن استخدام آنماط التصميم ما يأتي : 

® معرفة بطائفة واسعة من أنماط التصميم. 

6 تحليل المشكلات وتحديد أنماط التصميم الممكتة. 

6 تطبيق أنماط التصميم في شيفرة البرمجة التصميمية. 

8 تحديد أنماط التصميم في شيفرة البرمجة التصميمية. 

عندما کنا درس هندسة البرمجيات» بما في ذلك آنماط التصميم» أدركنا 
أن الطلاب كانوا يعانون مشكلة فهم أنماط التصميم وتطبيقها. فقد اكتفى بعض 
الطلاب بالنظر إلى نماذج نوع نمط التصميم المتوفرة في الفهارس المصورة» 
لكنهم لم يكونوا بالقدر الذي يسمح لهم ليستوعبوا مفاهيم تلك الأنماط 
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وسلوكها الديناميكي. لقد واجهوا صعوبات في تطبيق المعرفة لحل مسألة 
معطاف من حیث فصل مفاهيم نمط التصميم وتطبیقاتهاء وتحديد مفاهيم تمط 
التصميم المطبّق من شيفرة البرمجة المصدرية. على سبيل المثال» لاحظنا أن 
الطلاب يواجهون مشكلة في شرح النمط» وليس في شرح Îنlaٽ Java Mouse‏ 
Event Listener‏ . لم يكن هؤلاء الطلاب قادرين على رؤية المفهوم لقسه. 


لقد أدركنا آن الخبرة العملية مطلوبة لفهم واستيعاب تطبيق نمط التصميم. 
وعليه فقد طورنا مجموعة من التمارين على نمط التصميم مشروحة في هذا 
الفصل. ترتكز هذه التمارين على تطبيقاتنا في لعبة الکویکہات (Asteroids)‏ 
القديمة» حيث تبني الهدف لتطبيق نمط التصميم. نغطي هنا مفاهيم نمط 
التصميم عن طريق تى تصاميم النمذجة وتطبيق الأنماط في لخة 1۷ . لقد قمنا 
بتصميم التمارين لتكون أصغر حجماً وأكثر سهولة بحيث يستطيع الطلاب 
المبتدئون فهمها وإدراك ماهية التمارين في وقت قصير. إن النظام كبير بما فيه 
الكفاية بحيث تصبح مزايا تطبيق أنماط التصميم أكثر وضوحاً ولا تؤدي إلى 
المزيد من الأعباء التي قد تترتب عن تغيير النظام من دون الاعتماد على نمط 


. 


تصمیم. 
تدا ارين بتطام د العمل وج ار ی 
مرتكزاً على التمط إ إضافة إلى تطبيقهء وبناء اا لر اللي 


يوضح القسم 3 - 2 تصميم النظام العينة الذي نقوم بعرضه. ثمة درس عن 
تجميع وتنفيذ النظام ذ في القسم 3 - 3. أما تمارين تمط التصميم» فقد تم 
توضيحها في الأقسام من 3 - 4 إلى 3 - 9 وقد شملت المراقب والموائم ونمط 
الاستراتيجية. ونختم بالاستنتاج» حيث نوضح خبراتنا في تنفيذ الدرس في 


القسم 3 10. 


3 - 2 تصميم لعبة الكويكبات 


في هذا القسمء نوضح لعبة الكويكبات (sلاعاوة)‏ ونعرض التصميم 
الأساسي للنظام. جميع التمارين التالية تعتمد على هذا التصميم. 
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2-3 - 1 وصف اللعبة 


يتحكم اللاعب بالمركبة الفضائية على لوحة اللعب التي تمثل الفضاء 
الخارجي. هناك نوعان من الكويكبات التي تظهر على لوحة اللعب أيضاً: 
(أ) كويكبات صغيرة وسريعة» وهذه تغير اتجاهها فقط عندما تصطدم 
بأاطراف لوحة اللعب. 


(ب) كويكبات كبيرة وبطيئة» وهذه تغير اتجاهها دائماً. 


قد تغْيّر جميع الكوكيبات من سرعتها التي تتراوح من سرعة ضعيفة إلى 
السرعة القصوى. بإمكان اللاعب إطلاق الصواريخ وتغيير اتجاه وسرعة المركبة 
باستخدام لوحة المفاتيح. أما إذا صرب كويكب كبير بصاروخ فإنه يُستبدل بثلاثة 
كويكبات كبيرة وثلاثة كويكبات صغيرة. أما إذا ضرب كويكب صغير» فإنه 
بختفي. بعتبر اللاعب فائزاً إذا دمر جميع الكوكيبات. أما إذا اصطدمت المركبة 
الفضائية بأي كويكب فيْعتبر اللاعب خاسراً. يبيّن الشكل 1-3 لقطة للنسخة 
الأولية من لعبة الكويكبات. 


Arerods 


Cha for Anolied Soware [narnterina, TUM 2006 


الشكل (1-3): لقطة للعبة الكويكبات (لنه٣ء؛ء4)‏ الأولية 


بنا على وصف اللعبة» وفُرنا تصميماً أولياً في الشكل 2-3. نركز هنا على 
الأنواع الأساسية والمفاهيم» وأهملنا التفاصيل غير الضرورية. 
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في ها بأتي نصِفٌ الأنواع المبينة في الشكل 2-3. 
2-2-3 النوع : Game‏ 


پتکون من نوعين فرعي : ToolBar, GameBoard‏ . 


gêl recton{] 
+gelPos toni} 
'ga15poedl) 
rupCalEP odılgr 


ا 
+ıncıemen Spel)‏ 


+slarftbamat} 
+stlopû ame 
-moveSoliBodias{) 
-detectCollisionl) 


+iecremenlSpeedl) 


1 
sfurnlLetti} 
turnAightt 
BigAsterold SmallAatereid sfra Rocket) 


الشكل (2-3): التصميم الأول للعبة الكويكبات (خطط نوع بلغة النملجة الموحدة) 


ToolBar : النوع‎ 3-2-3 


هذا النوع هو عبارة عن مكوّن تصويري ويمثل أزرار البده والتوقف التي 


Solid Body : النوع‎ 4-2-3 


بعشل هذا النوع حالة تجريدية لجميع الكوائن التي تتحرك فوق لوحة 
اللعية. لهذا النوغ رله8لناه8 صفة تمثيل الصورة المستخدمة للتلوين. يتم 
تخزين انجاه الطيران في صفة الاتجاه. القيم المتاحة تتراوح من 0 إلى 360 
وتمثل الاتجاه بدرجة الزاوية. القيمة صفر تمثل الاتجاه عندما يكون مشيراً إلى 
الأعلى. صفة الموقع لها إحدائيان عمودي وأفقي وتخزن موقم yلSoli480‏ 
الحالي. كل رله#8ناه8 له صفة السرعة. جميع الصفات محمية ضد التعديل من 
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قبل الكوائن الغريبة. كما تتوفر عملیات المجlلبlٹات (Getter Operations)‏ 
للوصول إلى صفات النوع رله48ناهS.‏ تعمل العملية «هنازوه ۴ء ةفصن () على 
حساب الموقع الجديد وتثبيته في الصفة اعتماداً على قيم صقات السرعة 
والاتجاه. إذا وصل الموقع الجديد إلى حدود اللوحةء يتم تغيير اتجاه الجسم 
الصلب حسب القاعدة: زاوية السقوط تساوي زاوية الانعكاس. 


Asteroid : النوع‎ 5-2-3 


يمشل الكويكب الذي يتحرك على لوحة اللعبة. هذا النوع يستبدل قيمة 
عملية «0نانوم۴ )ةلمن () ويعمل على زيادة أو تقليل السرعة بشكل عشوائي. 


BigAstertoid : النوع‎ 6-2-3 

يخصص النوع لاهعاوهعا8 النوع 4 45)01 عن طريق إضافة وظيفة 
إضافية تعمل على تغيير الاتجاه عشوائياً. 

SmallAsteroid : النوع‎ 7-2-3 


يمشل الكويكب الصغير الذي يتحرك بسرعة أكبر من سرعة الأجسام في 
النوع BigAsteroid‏ . 


SpaceShuttle : ع‎ gill 8 2 3 


المركبة الفضائية هي جسم صلب يتحكم به اللاعب. يخسر اللاعب اللعبة 
إذا دمرت المركبة الفضائية. ويفوز إذا كانت المركبة الفضائية هي الجسم الصلب 
الوحيد الذي يتبقى على اللوحة. يوفر النوع عمليات عامة لتغيير السرعة 
والاتجاه وإطلاق الصواريخ. 

Rocket : انوع‎ 9-2-3 

يتم إنشاء الأجسام الصاروخية بواسطة العملية {ءkعءه ۴٣۸‏ () التابعة للنوع 
eلاeeSıtممS‏ . يكون اتجاه الصاروخ بالاتجاه تفسه للمركبة الفضائية وهو لا 
يتغير. تعمل الصواريخ على تدمير الأجسام الصلبة الأخرى. يتم حذف 
الصواريخ من اللوحة عندما تصل إلى حدود ل٣ة80ءصةي‏ أو عندما تصطدم 
بأاجسام صلبة أخرى. 
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GameBoard : النوع‎ 10-2-3 


يمشل هذا النوع الفضاء الخارجي للكويكبات. يتكون من العديد من 
الأجسام. في أثناء اللعب» تتحرك الأجسام الصلبة ضمن ل٣80aءصهي.‏ يرسم 
GameBoard‏ الصور للنوع 01B dies‏ في مواقعها. أما مواقع الأجسام الصلبة 
فتكون دائما ضمن سطح اللوحة. 


Referee النوع:‎ 11-2-3 


هذا النوع - ١ءإء]ء۴‏ هو المتحكم الرئيس في الكويكبات. وهو مسؤول 
عن بدء اللعبة والتحكم بها وإنهائها. عند بدء اللعبة يتم إنشاء عمليةُ Thread‏ 
منفصل للتحكم يقوم باستدعاء العملية sءله48ناه5٥«هص‏ () في فترات متكررة. 
هذه العملية moveSolid Bodies‏ (( تستدعى عملي ÎخضjرJ updatePosition‏ 0 
لجميع الأجسام الصلبة وتجبر ل٣ة80هصه‏ على إعادة رسمها ما يمكن 
B4‏ من التحرك. بعد تحريك جميع الأجسام الصلبة» تستخدم العملية 
detect o1اisien )..: Solid Body‏ لتحديد التصادمات. فهي تقوم بحساب إذا ما 
تقاطع جسماٹ 1رلهط و2رلهط وتقرر آي الجسمين يتم تدميره. والجسم الصلب 
الذي تم تدميره يُحذف. إذا تقاطع كويكبان» لا يتم تدمير آي منهما. إذا تقاطع 
كويكب آو المركبة الفضائية مع صاروخ» يتم تدميرهما. إذا تقاطع كويكب مع 
مركبة القضاءء یتم تدمير المركبة. بعد تحديد التصادمات باختبار النوع 
R۴۲٥‏ إذا ربح اللاعب آم خسر اللعبة. يفوز اللاعب إذا لم يتبقَ آي كويكب 
على اللوحةء ويخسر إذا دمرت المركبة الفضائية. فى هذه الحالات» أو إِذا 
استدعيت العملية ١«ة0صهاء‏ () يتم إيقاف عملية التحكم واللعبة. 


SpaceShuttleConttoller النوع:‎ 12-2-3 


يخضع هذا النوع إلى حركات لوحة المفاتيح والفأرة. ويتم استدعاء 
العمليات الخاصة بالمركبة الفضائية حسب هذه الحركات لتغيير الاتجاة والسرعة 
أو لإطلاق صواريخ جديدة. 
3- 3 تنزيل لعبة الكويكبات وتشغيلها 

يوضح هذا القسم كيفية تنزيل لعبة الكويكبات وتجميعها وتنفيذها. تم 
تطوير هذه اللعبة من قبل رئيس قسم هندسة البرمجيات التطبيقية في جامعة 
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مشروع لعبة الكويكبات ڏي كلمة المرور المحمية. يمکن طلب عنوان الصفقحة 
الفصل» نستخدم المتغير sلاهإءاو84‏ كمخزن لهذا العنوان. توفر البوابة 
الإإلكترونية بوابات فرعية لجميع التمارين والحلول. سنقوم بشرح عملية تجميع 
وتنفيذ النسخة الأولية للعبة الكويكبات الموضحة في القسم 2-3 . 

قم بتنزيل الشيفرة المصدرية للعبة من الموقع : http://SAsteroids/‏ < 
pî 1_InitialGame/downloads>‏ ف بفك ملف الأرشفة. ستجد الملفات 
والفهارس الآتية: 

© الفهرس STC‏ يتضمن جمیع ملقات الشيفرة المصدرية بلغة جافاء إضافة 

© الفهرس عا: يتضمن جميع ملفات كاماعء؟ اللازمة لبدء اللعبة من 

, Windows Linux, Mac 0S X > ةilتخم خلال متصات إطلاق‎ 

ص الملف اص×لانسطا: هذا هو ملف ا40 المسۋول عن تجميع اللعبة. 

لتجميع وتشغيل اللعبةء يتطلب الأمر وجودة Java1.‏ وAn-Apche‏ في 
الحاسوب. يمكنك تخطي الخطوات الآتية إذا كان كل من ۸۸۲ و&85 ۷۸ل 
مثبتان في الجهاز. 

۰ فم بتنزيل (1044«س00) 825 a«ه[)‏ الإصدار 1.5 أو إصدار أعلى. 


8 يمکنك تنزیل 5.0 4۷4328۴[ من الموقم التانئى : <http://java.sun.‏ 
com/]j2se/1.5.0/download,.jsp >‏ 


® ثبت جافا واتبع تعلیمات الْتثبيت. 
# ملاحظة: قد تتطلب بعض التطبيقات وجود المتغیر ۸۷۸_0۷٤‏ فى 
بيثة النظام. تأكد من وجود هذا المتغير» ومن أنه معد إعداداً صحيحاً. 


e‏ ف بتنزيل ( (Download‏ آخر إصدار من Apache-A)‏ من الموقع: 
http://ant.apache.org/bindownload.cgi‏ 


(Install) Û ®‏ مھ باتباع التعليمات الراردة في دليل الاستخدام 
lلخاص‏ ıڊ http://ant.apache.org/manualf/index.html : Apache Ant‏ 
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بعد تثبيت جافا و٤صة‏ بنجاح» يمكننا تجميع لعبة الكويكبات وتشغيلها. 
افتح سطر كتابة الأوامر» ثم افتح الفهرس الذي عملت على فكه مسبقاً. أما في 
شاشة (وس«ەل«W)»‏ فيبدأً تنفيذ الأوامر من سطر الأوامر Command Line)‏ 
«(Shell‏ بينما في النظم التي تعمل من خلال يونیکس (4غوھط-×iم0)»‏ 
يمكن استخدام أي أداة ك طهه8. توضح الخطوات التالية مهام 4۸١۲‏ والتي 
أخذت من الملف اص.لانسط الذي تم تحميله : 


e‏ اطبم آمر النجميع في |لÎدšl ant compile‏ لنجميم شيفرة البرمجة الخاصة 
باللعبة. يتم تجميع ملفات الأنواع المكتوبة بلغة جافا في فهرس أنواع جديد. 
يتم نسخ جميم ملفات الصور والصوت من الفهرس ٥ء‏ إلى فهرس 4عووهاء. 

® إن طباعة الأمر امه يستدعي الهدف التلقائيى المسمى لانسط الذي ينشىء 
الملفات التنفيذية لجميع منصات النظام المدعومة. سيتم إنشاء فهرس جديد 
يتضمن فهرسين فرعيين هما sلاهإعاو۸‏ و×05. يتكون الفهرس sلاهإعاوةه‏ من 
الملف ٣ه[.sل‏ هم Jaa Archie as)‏ الذي يحتوي على جمیم أنواع جافا المجمعة» 
إضافة إلى يامناءS‏ موںا٣ها5‏ لتشغيل اللعبة ضمن نظامى leÎ .Unixg Windows‏ 
الفهرس ×05 فيحتوي على الملفات التشغيلية اللازمة لتشغيل اللعبة ضمن نظام 
Mac OSX‏ . 

e‏ اطبع الأمر صمعاءامه لحذف الأنواع والفهارس. يمكننا تنفيذ لعبة 
الكويكبات» بعد تجميع الملقات وبنائها. يتم تجميع أنواع جافا المجمَّعة 
والمصادر ومعلومات البدء المتطلبة فى مlلف Java archive build/Asteroids/‏ 
٣وزولنەءاوة.‏ يتم تشغيل اللعبة عن طریق النقر بواسطة الفأرة نقرة مزدوجة 
على ملف ٣هز.ءلنهءماءه‏ وينطبق ذلك على جميع منصات الإطلاق. إضافة إلى 
ذلك» تنوفر ملفات البدء لما يأتي : 


Windows ®‏ : افتج المتصفح› ثم انتقل إلى الفهرس sلاه٣ع)ءui14/Aط‏ . 
أنقر مرتين على الملف اهط.ولذهإماوه, 


8 النظام المبني على ×نصل: افتح لاعطىء ثم انتقل إلى الفهرس /لانسط 
Asteroids.‏ لبدء اللعبة اطبع t. /asteroids.sh?‏ . 


pî Finder il :Mac OSX ®‏ انتقل إلى الفهرس ×05/لانسطا. انقر 
مرتين على تطبيق الكويكبات للبدء. 
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3- 4 التمرين الأول: نملجة نمط المشاهد 

في التمرين الأولء يجب أن يتم تغيير التصميم الأولي (انظر الشكل 3- 2) 
حتى يتوافق مع المتطلبات الأتية : 

يجب آن يرى اللاعب المعلومات المناسبة عن المركبة الفضائية في أثناء 
اللعب. يجب أن تتضمن هذه المعلومات سرعة المركبة الحالية واتجاهها 
وموقعها. حتى يتم إدراك المتطلبات؛ يجب أن تضاف لوحة للقياسات إلى 
نموذج التصميم الأولي للعبة. تتكؤن لوحة القياسات من الأدوات التي تعرض 
حالات المركبة كالسرعة والاتجاه والموقع. يجب أن يشتمل التصميم على 
الأدوات الجديدة» وبذا يتطلب تقارناً أقل للحد من أعباء التغيير التي قد تطرأ 
مستقبلا. الأدوات المتطلبة لهذا التمرين هي : 

#8 عداد السرعة ويعرض سرعة المركبة. 

_ بوصلة» وتعرضصس اتجاه المركبة. 

_ نظام تحدید المواقعم «GPS‏ ويعرضصس موقع المركبة. 

يجب أن تعرض هذه الأدوات التغيرات التي تطرأً على حالة المركبة 
الفضائية باستمرار. استخدم ٢eا†Pa server‏ برویدج B. Bruegge and A. H.)‏ 
"Dutt, 3‏ ص 702) لعرض تغييرات الحالة بواسطة الأدوات. 

مهمة التمرين 

# ارسم مخطط نوع بلغة النمذجة الموخدة» يشتمل على المتطلبات المعطاة. 

# ارسم مخطْط تتابع بلخة النمذجة الموحدة» يبيّن التفاعلات بين المركبة 

الفضائية والأدوات. 

یچب أن یرگز نموذج التمرين على مفاهيم Observer Pattern‏ ويچب أن 

هذا ويمكن اهمال التفاصيل المتعلقة بالأدوات كالبوصلة ونظام تحديد 
المواقع والأنواع الموجودة أصلاً غير المرتبطة بالحل. 


1-4-3 تموذج حل التمرين الأول 
يبيّن مخطط النوع بلخة النمذجة الموحدة في الشكل 3-3 تموذجاً لحل 
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التمرين الأول. تم عرض الأنواع ذاث العلاقة فقط مع الثركيز على ۲ء۷إموا0 
Pate‏ والدوات. 

أولاًء قمنا بإضافة أنواع نطاق التطبيق الموضحة في التمرين. قمنا بإنشاء 
نوغ جديد باسم nslrumentPanel‏ ويون من أدرات عديدة. أما النوغع 
عص فهو نظري فحسب ويوضح عمومياث عن الأنواع الخاصة 
بالأدوات الأساسية كاليوصلة وعداد السرعة ونظام تحديد المواقع. يقلل النوع 
sاrumenاو‏ من كمية الارتباطات بين 1عمو۴امعساوما والأدوات الملموسة. 
وبخلاف ذلك» سیکون للنوع 1٥۴4٤دعسناءما‏ ارتباط مع كل آداة من الأدوات 
الملموسة؛ كما سيتطلب الأمر إنشاء ارتباطات جديدة عند إضافة أدوات جديدة. 
لقد طبقنا دعااة۴ ٣ع«إموطا0‏ لإشعار الأدوات بالتغيرات التي تطراً على المركبة 
الفضاتية. في هله الحالةء يصبح النوع علااuط؟08٥هص8‏ بمثابة الناشر إذ إنه يوفر 
المعلومات عن الوضع الحالي» بينما يصيح النوع ٤١ء”نجاءها‏ بمابة المشترك. 
والمشترك حالة بمكن من خلالها الاشتراك آو عدم الاشتراك مع الناشرء 
وبالتالي مع النوع علااuط؟معمم؟.‏ إن عملية الإشعار رلنامد () الخاصة بالناشر 
تستدعي عملية التحديث ءاولون () لجميع الأدو اث المشتركة لإعلان تغيرات 
حالة المركبة. تنفل جميع الأدوات العملية عادلجد (). فهي تسترجع المعلومات 
المطلوية من لاا ط؟ت هم8 وتحدذّث المعلومات التي تعرضها عندما يتم استدعاء 
العملية عأملوں (), 


Publisher 


+rotify{} 
+subscnbe(s.Subscr lber} 
+unsubscribe{s :Subscriber 


+getDıreclion{} 
+getPosition) 
+getS5peedi) 


Î 


Compass Speedometer GPS 
+update() +update(j +updats() 


الشكل (3-3): تصميم الكوائن الذي يتضمن الأدراٽ و Observer Patio‏ 


+incrementSpeedt) 
lêcrernêntSûeedf) 
+turnLef{} 
+turnRAight{) 
+ireRockelt)} 
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يعرض الشكل 4-3 التفاعل بين الأدوات ممثلاً بمخطط تسلسل بلغة 
النملجة الموحدة. هذا العصميم قايل للعوسع» إذ لا يُلزم إجراء أي تغيير على 
الأنو 2 InstrumentPanely SpaceShuttle‏ وnstrument‏ ند إضافة أدوات 
جديدة. لاحظ أن التصميم يستخدم العديد عن حالات التورّث للنوع 
peh‏ وهلذه الخاصية غير مدعومة في بعض لغاث البرمجة. لقد وفرنا 
تصميماً ذا تنفيذ مستقل بوضح المفهوم. هذا ويمكن إدراك المفهوم باستخدام 
آي لغة برمجة. پجب آن لا يعكس التصميم تركيب تصميم النوع بالضبط. 


1 | :SnaceShunle 
Player _|L__Coniroller , \SRacrshutle | Lfampass J] 


۰ subscribe} 


p’eşs left ke : 
e turnLeht) 


subscriel) 


change dıredlıan 


notıfyı) updatel) 


gelPositiont} 


update) 


qet Dıre citron} 


الشكل (4-3): التفاعل بين المركبة الفضائية وأدواها 


3- 5: التمرين الثاني : Observer Pattern # ji‏ 
يركز التمرين الثاني على تطبيق التصميم الكائني الذي يتضمن ۲ء۷إموا0 
٣اا‏ من التمرين الأول. يعمل الثمرين على شيفرة تحويل العوامل المصدرية 
التي تنفُذ أجزاء القصميم. قم بشنزيل شيفرة الشحويل المصدري من الموقع : 

<http://$Asteroids/2_ObserverPattern Exercise downloads >‏ . 
ٍ فم بتجميع وتنفيذ اللعبة كما هو موضح في القسم 3-3. هذا وستجد أن 
عداد السرعة ونظام تحديد المواقع وصعااد۴ إe٣عوا0‏ منفذة من قبل بناء على 

التصميم الكائني من التمرين الأول. 
مهمة التمرين : 
نقذ 2 Comp‏ مبيناً تجاه المركبة. يجب أن ينشر النوغ عوهت النوع 
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nstrument‏ كما يچپ أن يتم إضافته إلى 1عہstrumen)۴a.‏ اعمل علی 
اشتراك النوع ووه في المركبة الفضائية لاستلام إشعارات عن التغيرات 
التي تطرأً على الاتجاه من المركبة. قبل البدء في التنفيذ» نرغب في شرح 
الأنواع الأساسية في هذا التمرين. يستخدم التصميم الوارد في التمرين الأول 
عددا من حالات التوزث للنرع SpaceShuttle‏ . لَغْة الجافا لا تدعم حالات 
القوزث العديدة. وبناء على ذلك» قمنا بدمج النوع ga Publisher‏ النوع 
SpaceShutte‏ عن طريق إضافة ال sلهطاعص‏ المطلوبة. 


public class SpaceShuttle extends SolidBody { 
private ArrayList < SpaceShuttleSubscriber > subscribers; 


public void incrementSpeed Û0 {...} 
public void decrementSpeed () {...} 
public void turn Right Û {...} 
public void tumLeft (0) {...} 

public void fireRocket Û {...} 


protected void setSpeed (int speed) { 

super.setSpeed (speed); 

notifySpaceShuttleSubscribers (0; 

} 

protected void setDirection (int direction) { 
super.setDirection (direction); 
notifySpaceShuttleSubscribers Û0; 

} 

public void subscribe (SpaceShuttleSubseriber subscriber) 
{...} 

public void unsubscribe (SpaceShuttleSubscriber subscriber) 
{...} 

public synchronized void notifySpaceShuttleSubscribers Û 
{...} 

} 
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لاحظ الفروقات بين التصميم والتطبيق. في التصميم» کنا قد أضفنا النوع 
ubseriber‏ لہیان آنتا نستخدم bserver Pattern‏ » حیث یمکننا أن نميّز هذا 
النوع من خلال واجهة الجافا التي تعرف ب م طاإوSpaceShuttleSub‏ . يشير 
الاسم إلى ن المشتركين يمكنهم الاشتراك في المركبة الفضائية وزيادة القدرة 
على قراءة شيفرة البرمجة. يتعرّف النوع eاSpaceShutt‏ على الواجهة 
SpaceShuttleSubseriber‏ التي قد تكو عبارة عن آي نوع تنفيذ. لا یحتاج النوع 
SpaceShuttle‏ إiى‏ آي تعديلات إذا أضيفت آنوا !2 SpaceShuttle Subscriber‏ 
جديدة. 


ublic interface SpaceShuttleSubscriber { 


void update Û0; 
} 


يعمل النوع ١١عسں‏ )وما النظري المكتوب بلغة جافا على تنفيذ 
SpaceShuttle Subscriber‏ ويiشر‏ النوع JPanel‏ المستخدم لتخزين الر سوم 
خاص ب عصنس؟. يعمل النوع ۸۲٣٥”ںآ٣‏ )وم1 متغير محمي یمکن أن تستخدمه 
الأنواع الفرعية لاسترجاع معلومات المركبة الفضائية وعرضها. بإمكان الأتواع 
الفرعية كعداد السرعة أن تضيف مكرنات هد8 رسومية لعرض معلومات 
المركبة. يتم استدعاء العملية عادلمں () عندما تتغير صفات (خصائص) النوع 
SpaceShuttle‏ . 


public abstract class Instrument extends JPanel implements 
SpaceShuttleSubseriber { 

protected SpaceShuttle spaceshuttle; 

public Instrument (SpaceShuttle spaceshuttle) { 
this.spaceshuttle = spaceshuttle; 

} 

public abstract void update (); 

} 


ثمة نوع آخر يستخدم لتخرین عصاس5 الرسرمية وھ cInstrumentPanel‏ 
ويتضمن جميع الأدوات. يعمل هذا النوع على إنشاء حالات الأدوات ويشاركها 
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فى #لااسط#8مهم؟. الجزئية الآتية تتضمن شيفرة البرمجة التى تبين تهيئة عداد 
السرعة ونظام تحديد المواقع : 


public class InstrumentPanel extends JToolBar { 


public InstrumentPanel (SpaceShuttle theSpaceShuttle) { 
super (JToolBar. VERTICAL); 

setFloatable (false); 

this.spaceshuttle = theSpaceShuttle; 


speedometer = new Speedometer (theSpaceShuttle); 
theSpaceShuttle.subscribe (speedometer); 

add (speedometer); 

gps = new GPS (theSpaceShuttle); 
theSpaceShuttle.subsceribe (gps); 

add (gps); 


3- 5 - 1 تموذج حل التمرين الثاني 

في ما يأآتي نعرض الأجزاء الرئيسة من حل التمرين الثاني» بيد أنك 
تستطيع تنزيل الشيفرة البرمجية كاملة من الموقع: /ولأهماوه8//:واا> 
2_ObserverPatternSolution/downloads >‏ 

آولا شىء النوع مده المتطلب الذي يوسم التوع التظري ٤٣عصن٤وم!.‏ 
نضيف النوع J141‏ لمستوعب النوع Instrument‏ التي تعرض اتجاه المركبة 
الفضائية كنص. نقوم بتعديل النص كلما تم استدعاء العملية ءادلمں () كلما 
تغير الاتجاه. 
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public class Compass extends Instrument { 

private JLabel theLabel = new JLabel ("", JLabel.CENTER); 
public Compass (SpaceShuttle spaceshuttle) { 

super (spaceshuttle); 

setLayout (new BorderLayout 0)); 

add (theLabel, BorderLayout.CENTER); 
theLabel.set Text (get Text (spaceshuttle.getDirection 0)); 
} 

public void update () { 

String newText = get Text (spaceshuttle.getDirection Û); 
if (tnewText.equals (theLabel.getText 0)) { 
theLabel.set Text (new Text); 

} 

} 

private String get Text (int direction) { 

return "Direction: " + direction; 

} 

} 


ثانياًء تُنشىء حالة جديدة ونشركها فى عاااط5ءهم8 وتضيفها إلى 
InstrumentPanel‏ „ 


public class InstrumentPanel extends JToolBar { 


public InstrumentPanel (SpaceShuttle theSpaceShuttle) { 
super (JToolBar. VERTICAL); 


compass = new Compass (theSpaceShuttle); 
theSpaceShuttle.subscribe (compass); 
add (compass); 
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3 - 6: التمرين الثالث: نمذجة نمط المراثم 

يرقز هذا التمرين على مسأآلة دمج مكوّنات البرمجية غير القابلة للتعديل التي 
لا تناسب تصميم النظام قيد التطوير. إما أن تكون هله المكونات من مصادر 
خارجية أو نظم قديمة معوارثة توفر الوظائف المطلوبة. في التمرين الثالث» أضفنا 
انوع ماع0 لeعp؟عاومة‏ إلى مشروع لعبة الكويكبات وهذاالنوع يعرض 
السرعة بواسطة إبرة مؤشر لکنه لا پزيد على النوع أدعصس)5دآ ولا يتيم 
Observer Patten‏ من الشمرين الأو ل كما لا یعرف SpaceShutlle gail‏ 
«اتظر الشكل 53). يوفر النوع اعاءصلءءم5عملهمة العملية المشتر ك عاعمهاعة 
(٤مة:عاعمه)‏ التي تحدد زاوبة أيرة عداد السرعة. وتكون قيمها من 0 إلى 180 


درجة. 

مهام التمرين 

AnalogSpeed omcter ual ۳ + ارسم مخظط نوع بلغة النمذجة الموحدة‎ e 
في آلية ا٤٠۴ عوط (انظر الشكل 53)ء بحيث تعرض سرعة المركبة‎ 
على آنه نوغ‎ AnalogSpeedometer الفضائية الحالية داثماً. يشم التعامل هع النوع‎ 
متوارث لا يمكن تعديله. آما تمط الموائم» فيجب أن يستخدم لعملية الدمج‎ 
„(697 e «B. Brucgge and A. H. Dutoit, 2003) Jalكتily‎ 


۵ ارسم مخطّط تسلسلِ بلغة النمذجة الموخدة» يوضح السلوك الديناميكي 
الذي پتبعه نمط المو اتم عند تأر Analog Speed0¢e¢r‏ . 


Publisher 


+body:tmage 
Fdireclion 
#posilion 
#speed 
+getDıreclont) 
+galPositonl} 
+gelSpeedl] 
L+updalePosrıon 


+nolnly 
+suhscnbats Subscriber] 
+unSUbScrbE{3:5u bscribet] 


InstrumentPanat » Instrument 
+upaatey) 


SpaeeShunle 
+incrorenlSpeed[) 


efırgRockgl() 


Gampass j Speedometer [ analeqSpeedometer 
[rugaael | et = E1 


الشكل (5-3): خطط يوضح النوع ا لمر ار ڌ AnalogSpeedometer‏ الذي جب آن 
يكون مدا في تصميم اللعبة ولا يمكن تعديله 
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1-6-3 نموذج حل التمرين الثالث 

بين مخطط النوع بلغة النمذجة الموحدة في الشكل 63 دمج 
Anal ppcedomcter‏ في sلاەاما4‏ باستخدام نمط الموائم. لقد حذفنا جميع 
الأدوات التي عرفناها مسبقاً لزبادة مستوى القراءة. برتبط النوع الموائم مع 
A20 gpeedometer‏ وپزپد على النوع ٤١عساومآ‏ ليتناسب مع تصميم 
Observer Pattern‏ 


Publisher 


TT 8 rher * Subscriber 
+subserbets:Subscnibar} +update 
1 N 


+tnsubscnbels:Subscr be) 


+Dody Image 
#dirêcîion 


#posihon 
#spêed 1 
+gelDıreciton(} 
+gelPostıont)} 

+ge!Şpeed} 


ت 
و 
+O‏ 
+inçrementspesd)‏ 
+decremenlSpeedl)‏ 
س +urnLeft}‏ 
aurnRight) Analog Speedometer AnalogšpeedometerAdapter.‏ 
ِ ا +fire Rocket)‏ 
+selAngielangle inl +updalê‏ 


الشكل (3- 6): نموذج الحل لدمج النوع ما٤«‏ هل٥ءم؟ع‏ اود عن طريقق تطبيق 
نمط الوائم 


£ iSnaceShatile . ': AnalogSpeedometer :Analng 
Player — kakpaller [Sraceshyrle Adapter | saad er | 


subsenbel} 7 


۱ 
ج ! 

ress up key - 
۶ 2 1 ımcramênl Speed) 


change speed 


nolify} 
upoalef) 


qeîSpeedl} 
comipule angl# 


şelAngled} 


الشكل (7-3): طط تسلسل بلغة الدمذجة الموحلة يوضح السلوك الديناميكي 
AnalogSpeedometer Û‏ المج Adapter Patter ةطnl yg‏ 
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يبيّن الشكل 3 - 7 مخططاً تسلسلياً بلغة النمذجة الموحدة» يوضح السلوك 
الديناميكي أعملية التكامل. النوع Anal SpeedometerAdapter‏ هو مشترك في 
المركبة الفضائيةء ويتم استدعاء العملية ءادلمں () عندما تتغير أي من خصائص 
المركبة. تسترجعم العملية eاةلمں‏ () السرعة الحالية من المركبة» وتحسب 
الزاوية لعداد السرعة إ#ا#صهلممم؟ علومة الذي يجب أن لا يتغير. 


Adapter Pattern û#j : التمرين الر ابع‎ 7 -3 


في التمرين الرابع» نقوم بتطبيق عملية تكامل ۲٣٠۲١‏ امهل الموضحة 
في القسم 6-3. هذا ويمكن تنزيل الشيفرة البرمجية للتمرين من خلال الموقع : 


< http://ŞAsteroids/3_AdapterPattern Exercise/downloads > 


لقد أضفنا ملف نوع جافا المسمى ه«هز.إءاءص0لعءم5عهله«ة إلى الحزمة 
legacysystem‏ التي تتحقق من عداد السرعة التناظري. أما النوع الخاص بعداد 
السرعة التناظري ١ءاءصهلهمم؟‏ فيعمل على توسيع النوع 1ءمة۴[ وهو مُضاف 
صل إلى المستوعب الجغرافي اعم ۴ءادعصu‏ وما . 


public class InstrumentPanel extends JToolBar { 
public InstrumentPanel (SpaceShuttle theSpaceShuttle) { 


analogspeedometer = new AnalogSpeedometer Û0); 
add (analogspeedometer); 


} 


بعد تجميع وتنفيذ اللعبةء ستقدرك أن عاد السرعة التناظري لا يظهر 
السرعة الحالية للمركبة الفضائية. 

مهمة التمرين 

دمج عذاد السرعة التناظري مع النظام باستخدام نمط التكيّف. 


۵ إنشاء نوع جافا جدید باسم »AnalogSpeedometerAdapter.java‏ حیث 
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يقوم هذا التوع بتطبيق نمط التكبّف» كما هو مبيّن في القسم 6-3. يجب آن 
ينقل السرعة من المركبة الفضائية إلى عداد السرعة التناظري. هذا ويجب آن لا 
تخر nÛİlلف AnalogSpeedometer.java‏ آبداً. 


1-7-3 نموذج حل التمرين الراب 

يمكن تنزيل الشيفرة البرمجية الكاملة لحل التمرين الرابع من الموقع: 

نقو ۴ بإنشاء النوع AnalogSpeedometerAdapter‏ في حزمة أدو ات لعبة 
الكويكبات. تم توفير حالة النوع Anal gSpeedometer‏ المکیف فی المنظم وتم 
إعداده على أنه متخير خاص للحالة. يعمل النوع ءاه لءءم5 عه اهمه المكيف 
على توسيع انوع ٣ص‏ اوم1. إن تطبيق ال لطاع الخاصة بالتعديل eاولصں‏ 0© 
يعمل على استرجاع السرعة الحالية للمركبة ويحسب زاوية عداد السرعة التناظري. 


لتقليل عمليات الحسابات غير المرغوب بهاء نقوم بتخزين قيمة آخر سرعة للمركبة 
فى متغير خاص بالحالة وحساب الزاوية فقط عندما تكون السرعة الحالية مختلفة. 


public class AnalogSpeedometerAdapter extends Instrument { 
private AnalogSpeedormeter adaptee; 

private int speed; 

public AnalogSpeedometer Adapter (SpaceShuttle spaceshuttle, 
AnalogSpeedometer analog speedometer) { 


super (spaceshuttle); 

this.adaptee = analog_ speedometer; 
update 0; 

} 


public void update Û0 { 

if (this.speed! = spaceshuttle.getSpeed 0) { 

this.speed = spaceshuttle.getSpeed Û; 

double percent = 1.0d/(double) spaceshuttle.getMaximumSpeed 0 
* (double) this.speed; 

int angle = (int) ((double) adaptee.getMaxAngle Û * percent); 
this.adaptee.setAn gle (angle); 
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لتمكين آلية التكيّف› نقوم بتعدیل النرع 1nstrumentPanel‏ عن طریق إنشاء 
Anal oÊSpeedometerAdaptet all>‏ جديدة» ومن ثم الاشتراك بها فى المركبة 
القضائية. 


public class InstrumentPanel extends JToolBar { 


private AnalogSpeedometer analogspeedometer; 
private AnalogSpeedometerAdapter analogspeedometeradapter; 


public InstrumentPanel (SpaceShuttle theSpaceShuttle) { 


analogspeedometer = new AnalogSpeedometer Û; 


analogspeedometeradaptet = new AnalogSpeedometerAdapter (spaceshut- 
tle, 


analogspeedometer); 
theSpaceShuttle.subscribe (analogspeedometeradapter); 
add (analogspeedometer); 


} 


3 - 8 التمرين الخامس: نمذجة نمط الاستراتيحية 

في نظام لعبة الكويكبات يكون النوع ءءإءfءR‏ مسۇولاً عن تحدید 
التصادمات بين الأجسام الصلبة المختلفة. بعد فترة زمنية» يحرّك النوع م0مم 
كل جسم من الأجسام ويحدد آياً من الأجسام الصلبة يتقاطع مع غيره. 
يستخدم هذا النوع «0اوالاه٣)ءعاءل‏ () - المبين في شيفرة البرمجة المصدرية 
الآتية - لتحديد التقاطع بين جسمين. تأخذ هذه ال لهطاءص كائنين من نوع 
S08 0dy‏ كعوامل. إذا حدث التقاطع» يتم استرجاع الجسم المدمر 
laÎ +SolidBody‏ إن لم يحصل التقاطم» يتم استرجاع القيمة الاد. تستخدم 
الأنو ع الفرعية للعو امل - وهي Rocket «SpaceShuttle « Astroids‏ _ لتحدید 
ما إذا تحطم الجسم. إن استراتيجية التصادم المطبقة سهلة للغاية: إذ تتحطم 
المركبة الفضائية عندما تتقاطع مع آي جسم آخرء أما إذا تقاطعت الكويكبات 
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مع بعضها بعضاً فإنها لا تتحطم» آما الصاروخ فيعمل على تدمير الأجسام 
الأخرىء لكنه لا يُحطم ذاته. 


public Solid Body detectCollision (Solid Body solidbody1, Solid Body 
solidbody2) { 

Point p1 = GarmeBoartd.getlnstance (.convertPosition( 
solidbody1.getPosition Û0); 

Dimension dl = solidbody1.getSize Û0; 

Rectangle r1 = new Rectangle (p1, d1); 

Point p2 = GameBoard.getInstance ().convertPosition ( 
solidbody2.getPosition Û0); 

Dimension d2 = solidbody2.getSize Û; 

Rectangle r2 = new Rectangle (p2, d2); 

if (rl intersects (r2)) { 

if (solidbody1 instanceof SpaceShuttle) { 

return solidbody1; 

} else if (solidbody2 instanceof SpaceShuttle) { 

return solidbody2; 

} else if (solidbody1 instanceof Rocket) { 

returm solidbody2; 

} else if (solidbody2 instanceof Rocket) { 

returm solidbody1; 

} else { 

return null; 

} 

} 

return null; 


} 


لهذا التطبيق عدة مساوئ: الشيفرة البرمجية للعملية «i0ونااد1ءعdet‏ © 
صعبة القراءة» لأنها تحتوي على جمل شرطية في العديد من المستويات 
المتداخلة. إضافة إلى ذلك» يتم إدراك استراتجية التصادم خارج النوع 
yل0‏ 01148 وأنواعه الفرعية. كنتيجة ذلك من الصعب إضافة متطلبات جديدة› 


على سبيل المثال: 
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يجب آن يكون لاعب لعبة الكويكبات قادرا على تغيير استراتيجية تصادم 
المركبة الفضائية فى أثناء فترة التنفيذ. 

حتى تكون قادرا على التعامل مع أنواع المتطلبات هذه» نقوم بعمل 
مراجعة للشيفرة البرمجية المصدرية وتحولات النموذج في مخطط النوع : 

1. مراجعة الشيفرة البرمجية المصدرية. نستخلص وظيفة التحقق مما إذا 
كانت الأجسام الصابة تتحطم وننقلها إلى عملية جديدة لهطاءص تدعى : 

+ collide (body:SolidBody):boolean of the class Solid Body 

وبناء على ذلك» سیکون على ١٥۲ء]ه۸‏ اكتشاف إذا تقاطع جسمان صلبان» 
ویستعالم ما إذا تحطم الجسمان وذلك عن طريق استدعاء العملية علااآهء (). 

يبيّن المقطع الآتي من الشيفرة البرمجية التغييرات التي تحدث في النوع 


„ Referee 


private void moveSolid Bodies 0 { 

GameBoard gameBoard = GameBoard.getInstance Û; 
SolidBody[] solidbodies = gameBoard.getSolidBodies 0; 
int max_x = gameBoard.getSize 0(.width; 


int max_y = gameBoard.getSize (.height; 

for (inti = 0;1 < solidbodies length; 1+ +) { 
solidbodies[i].updatePosition (max_x, max_y); 
} 

gameBoard .repaint Û; 

HashSet < Solid Body > crashedBodyCache = new HashSet < SolidBody > Û0; 
for (int z = 0; z < solidbodies.length; z+ +) { 
SolidBody solidbody1l = solidbodies[z]; 

if (crashedBodyCache.contains (solidbody 1)) { 
continue; 

} 

for (inti = 0;1 < solidbodies,length; 1+ +) { 
SolidBody solidbody2 = solidbodies[i]; 

if (solidbody1l = = solidbody2) { 

continue; 

} 

if (crashedBodyCache.contains (solidbody2)) { 
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continue; 

} 

boolean collision = detectCollision (solidbody1, solidbody2); 

if (collision) { 

boolean isCrashed = solidbody1 .collide (solidbody2); 

60 TEACHING DESIGN PATTERNS 

if (isCrashed) { 

crashedBodyCache.add (solidbodyD); 

GameBoard.getInstance (.removeSolid Body (solidbody1); 

} 

isCrashed = solidbody2.collide (solidbody1); 

if (isCrashed) { 

crashed BodyCache.add (solidbody 1); 

GameBoard.getInstance 0(.removeSolid Body (solidbody2); 

} 

} 

} 

} 

if (tfgameBoard.hasSolid Body (gameBoard.getSpaceShuttle 0)) { 
stopGame 0; 

JOptionPane.showMessageDialog (null, "You lost the game in " 
+ gameduration_in_seconds + " seconds!", "Information", 
JOptionPane.INFORMATION_MESSAGE); 

int index = (int) (Math.random Û * (double) gameoverClips.size (0); 
AudioClip clip = (AudioClip) gameoverClips,. get (index); 
clip.play 0; 

initGame Û; 

} else if (GameBoard.getInstance (.getSolid Bodies O(.length = = 1) { 
stopGame Û; 

JOptionPane.showMessageDialog (null, 

"Congratulation, you won the game in " 

+ gameduration_in_seconds + " seconds!", 

"Information", JOptionPane INFORMA TION_MESSAGE); 
initGame Û0; 

} 


} 
public boolean detectCollision (SolidBody solidbody1, SolidBody 
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solidbody2) { 

Point p1 = GameBoard.getlnstance (.convertPositiorl 
solidbody1.getPosition Û); 

Dimension d1 = solidbody1 .getSize 0; 

Rectangle r1 = new Rectangle {p1, d1); 

Point p2 = GameBoard. getinstance (.convertPositior 
solidbody2.getPosition 0); 

Dimension d2 = solidbody2.getSize Û0; 

Rectangle r2 = new Rectangle {p2, d2); 

if {rl.intersects {r2)) { 

return true; 

} else { 

return false; 

1 

} 


2. التحول في النموذج. بييّن الشكل 3 - 8 مخطط النوع بلغة النمذجة 
الموحدة حسب التغيرات الموضحة أعلاه. يستدعي النوع ١٣ء۸‏ العملية 
...) eلiلاoه)‏ من الأحداث الخاصة يالأجسام الصلبة رله48ناه؟ عندما تكون 
نثيجة عملة التحقّق «بنونلام)اءعاعل () إيجابية. 


لاحظ أننا تعرض الأنواع ذات العلاقة فقط. 


SolidBody | 
+body:lmağgeê 
+startGameû #Qirection 
+S1o0pGame{)} #positign 
-movsSalid Bodies} 7 TT #speed 
-deleclCallisionfj:boale ars +getDirectionl) 
+gelPosition() 
+jêSpeed) 
+updatePositiont{) 
+callidefbody :SolidBody}:boolean 


SpaceShutile 
Aoûcket Asteroid 
+incremêerlSpetdi) 


+GecrementSpee dj} 
+turnLeft) 
+turnRighl) 
BigAateroid | Small Asterold | +tireRocket) 
الشكا (3 - 8) : غخطط الصنف 011 يبن الشفير اث المر اجعة؛ ويقتصب ال‎ 
یں السعے . وبر‎ 
الأصناف ذات العلاقة‎ 
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مهمة التمرين 

لتحقيق المتطلب «تغيير استراتيجية التصادم للمركبة الفضائية في فثرة 
التنفيذة» فإن مهمة التمرين تطبيق نمط الاستراتيجية في مخطط النوع بلغة 
النمذجة الموحدة. 

ê‏ يجپ أن يشم إدراك استثراتيجية التصادم في نوع منفصل يدعى 
iin Stray‏ . هذا النوع نظري فحسب ويجب أن يوفر العمليات النظرية التي 
تحدد وظيفة عملية (...) لاء بحيث يثمكن النرع رل 08ناه؟ من تفويض النوع 
Cision Strategy‏ يإداء جميع طلبات التنفيذ. 

# يوفر استراتيجيات تصادم متمكنة للمركبة الفضائية والانواع الخاصة 
بالکویکبات. 

توفير عمليات لتغير استراتيجيات التصادم في فثرة التنفيذ. 


3- 8 - 1 نموذج حل التمرين الخامسس 


»body inage 
Fdrectipn acohletbady Soft Body} boolean 
orion Nema: Srmg 


ap Oreo 


 SRANRSRHCoNlelonSIralegy | 


+EalkCA{bony SotiBady] boolean 
+gaN2 rel. Stnnmg 


+ updaleP şon} 
scallalelbody ‘Sotdflocly} boote: 


BiqAsloralaCalnlon Strategy 


Cave SerdBody) boolean 
tgjelNamaj) Song, 


+B Rochel) 


الشكل (3- 9): خطط الصنف ا01 يبين فصل (Decoupling)‏ الأجسام الصابة 


rz 


واسٹراتیجیات | رتطامها باستخدام نمط الاسثراتيجية يجي 


im 


يبن مخطط النوع بلغة النمذحة الموحدة ف في الشكل 9_3 استخدام نمط 


الاستراتيجية للشحقق من حدوث تغيير في استراتيجياث التصادم في أثناء فثرة 
الشنفيذ. پستدعې النوع Referee‏ العملية (...) ideلاco‏ من النوع Solid Body‏ وھا 


النوغ يفوض ععاةعا8«مننلامت المرتبط بتنفيذ الطلب لاه . يجيب النوع الفرعي 
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الخاص بتنفيذ استراتيجية التصادم الحاليةف ومن ثم يعيد النرع SolidBody‏ 
نتيجة التنفيذ إلى ١ءءءء]ء۸.‏ النوع الفرعي غير معروف للنوع yل11480اه8‏ 
وقد پتغیر فی أثناء فترة التنفيذ بواسطة العملية (...) رعع ا4٣25‏ 10اه )مء. لقد 
أضفنا العملية getName ):String‏ التي تعطي عن تنفيذها اسم استراتيجية 
التصادم الذي سيستخدم لعرض استراتيجية التصادم الحالية. الان تم توسیع 
لعبة الكويكبات لتشمل استرتیجیات تصادم جديدة من دون تعديل النوعين 
Referee‏ وڪ Solid Body‏ . 


يرتكز التمرين السادس على شيفرة تحويل العوامل للعبة الكويكبات» التي 


يمكن تنزيلها من المو قع : http://SAsteroids/4 _StrategyPatternExercise/‏ < 
downloads >‏ 


لقد نفذنا التصميم المبيّن في القسم 8-3. توجد أنواع نمط الاستراتيجية 
ضمن الحزمة sعاعماaء)و«منونلاوء.‏ تبيّن الشيفرة الاتية النوع النظري 
isionstrategyااەc.‏ يتطلب تنفيذ الأنواع الفرعية مرجعاً للأجسام الصلبة التي 
تستدعي العملية (...) #فنلامت لأجلها. وبتاء على ذلك يوفر النوع CollisionStrategy‏ 
متغير خاص ذو عمليات «جلب) (۲عا)عع) واتحديدا )8e)18۲(‏ مناسبة. 


public abstract class CollisionStrategy { 

private SolidBody solidBody; 

public void setSolidBody (SolidBody solid Body) { 
this.solid Body = solid Body; 

} 

public SolidBody getSolid Body 0 { 

return solidBody; 

} 

public abstract boolean collide (Solid Body opponent); 
public abstract String getName Û0; 

public String toString Û { 

returm getName (Û0; 

} 

} 
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يبيّن المقطع الآتي من الشيفرة البرمجية النوع yفه48ناه8.‏ هذه 
الشيفرة تفوض استراتيجية التصادم الحالية بتنفيذ التصادم وتوفر العمليات 
اللازمة لاسترجاع وتخيير الاستراتيجية. يتم استدعاء العملية (...) رل11380اه8)ءء 
في نوع استراتيجية التصادم من العملية ...( set o1اision Strategy‏ في النوع 
SolidBody‏ . 


public abstract class Solid Body { 


private CollisionStrategy collisionStrategy; 
public SolidBody (Point position, int direction) { 


setCollisionStrategy (new DefaultCollision 0); 
} 


public boolean collide (Solid Body solidbody) { 
return collisionStrategy.collide (solidbody); 

} 

public void setCollisionStrategy (CollisionStrategy 
collisionStrategy) { 

if (collisionStrategy = = null) { 

throw new Illegal Argument Exception’ 

"The given collision strategy is null. "); 

} 

if (this.collisionStrategy! = null) { 
this.collisionStrategy.setSolid Body (null); 

} 

this.collisionStrategy = collisionStrategy; 
this.collisionStrategy .setSolid Body (this); 

} 

public CollisionStrategy getCollisionStrategy 0 { 
return collisionStrategy; 


} 
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یک ی گیا پا کا و و کت 
التعلميات (انظر اللقطة في الشكل 10-3). تعرض القائمة استراتيجة تصادم 
المركبة الفضائية الحالية وتتضمن جميع الاستراتيجية الموجودة ضمن حزمة 
isionstrategiesلاo‏ التي يتم ا وباک عن طرق استخدام [ava‏ 
مەتاءR6.‏ هذا ويمكن تغيير استراتيجية التصادم في فترة التنفيذ. 


saa Asteroids 
File Control 


mart 


speed up 


lek fire rocket rig 


Collision Strategy [Space Shuttle Collision EE} (reload 


Û You Space Shunt 


DirşcUan: © 


E 


Spend 1.0 
CPS Coords: 0246 | 0216 


new winoom 


UN 2006 


الشكل (3- 10): لقطة لشاشة لعبة الكويكبات تنضمن اختيار امثراتيجية التصادم 

مهمة التمرين 

© تنفيذ أستراتيجية تصادم جديدة تسمح للمركبة الفضائية التصادم مع ثلاثة 
كويكبات قبل أن تتحطم. يجب أن تكون الاستراتيجية الجديدة متوفرة ضمن 
الحزمة sعاععاa٣اs«نونلامه.‏ ويخلاف ذلك»ء لن تعثر آلية تحميل النوع 
الديناميكية من العثور عليهاء 

يمكن تنزيل الشيفرة البرمجية المصدرية الكاملة لنموذج حل التمرين 
السادس من الموقع : 

لقد نفُذنا النوع SpaceShuttle Credits‏ الذي يوسع النوع Space Shuttle‏ 
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Cision Strategy‏ ویعید استخدام تلفي العملية (...) ءفالآهء التابعة له. للتحقق 
من المتطلبات المطلوبةء أضفنا عدّاداً يدعى #االه» وهو يتفعل بالقيمة 3. تقل 
قيمة العداد عندما تكون نتيجة تنفيذ العملية (..) ءل نلاه إيجابية. هذا وتكون 
نتيجة ننفيذ النوع SpaceShutle3Credis‏ خاطئة إلى أن تصل قيمة العداد إلى 
0. يتطلب تقاطع جسمين صلبين بعض الوقت قبل أن ينفصلا ثانية. لتجنب 
انخفاض قيمة العداد إلى 0 ضمن حالة تقاطع واحدة» نقوم بتقليل قيمة العداد 
خلال فواصل زمنية» مدة كل منها ثلاث ثوان. 


public class SpaceShuttle3Credits extends 
SpaceShuttleCollisionStrategy { 

private int credits; 

private long lastCrashInMillis; 

public SpaceShuttle3Credits O0 { 

super (); 

credits = 3; 

lastCrashInMillis = System.currentTimeMillis O; 
} 

public boolean collide (Solid Body opponent) { 
boolean isCrashed = super.collide (opponent); 
if (isCrashed && credits > 0) { 

if ((System.current Time Millis’ 
-lastCrashInMillis)/1000 > 3) { 
lastCrashInMillis = System.currentTimeMillis Û0; 
credits; 

} 

return false; 

} else { 

return isCrashed; 

} 

} 

public String getName Û { 

returm "3 credits"; 

} 

} 
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3 - 10 الغبرات والاستتتاجات 

لقد طبقنا المنهج الذي زودنا به على أنماط التصميم مرات عديدة في بيئات 
تعليمية مختلفة. استخدمنا التمارين فى محاضرات هندسة البرمجيات فى جامعة 
ميونيخ التكنولوجية في فصول الشتاء للأعو ام الدراسية 2005/2004 و2006/2005. 
حضر حوالى 100 طالب» من الفصل الثالث» دروساً عملية أسبوعية» نفّذنا 
خلالها تمارين التمذجة بشكل تفاعلي مع الطلاب. كنا نناقش المشكلة ثم نطلب 
من الطلاب كتابة الحل على الورق» وكتا نقدم المساعدة الفردية لهم. ومن ثم 
كان أحد الطلاب يعرض نموذج الحل خاصته قبل أن نقدم لهم الحل ونناقشه. 
كان على الطلاب إنجاز تمارين البرمجة كل على جِدَّة خلال الأسبوع. 

لقد نفذنا تمارين لعبة الكويكبات ضمن منهج دراسي عن التطوير الذي 
تحكمه الأنماط خلال الدورة الصيفية الدولية التي عقدت عن هندسة 
البرمجيات. لقد حضر طلاب الشهادة الجامعية العلیاء الدکترراه (2.ط۲)» 
المحاضرة ذات الأريع ساعات التي تضمنت معرفة عميقة بآتماط التصميم 
والتطوير كائني التوجه والبرمجة. 

استخدمت باتریشیا لاغو (0عھ[ aاءا٤٤ه۴)‏ التمارين لتدريس أنماط التصميم 
ضمن منهاج هندسة البرمجيات في جامعة زا۷۶ أمستردام في ربيع عام 
6 . يركز منهاج هندسة البرمجيات على المبادئ النظرية لهندسة البرمجيات 
ويغطي أنماط التصميم في أسبوع واحد فقط. شارك حوالى 120 طالب من الستة 
الثانية في درجة البكالوريوس علوم الكمبيوتر في محاضرة» وقسموا إلى 
مجموعات تضمنت کل منها 30 طالبا. نفذت کل مجموعة من المجموعات مادة 
الدورة في مختبر الحاسوب. بدأ المنهاج بعرض مدته 15 دقيقة عن أنماط 
التصميم بشكل عام. ثم تم تقديم كل تمرين بما في ذلك نمط التصميم المرتبط 
به لمدة 15 دقيقة» ومن ثم قاموا بحل كل تمرين على جدة في مدة 30 دقيقة. 
تلقينا انطباعات إيجابية عن تنفيذ تلك المادة التعليمية. 

لقد كانوا قادرين على تعليم أنماط التصميم بما في ذلك الخبرات العملية 
ضمن فترة محدودة وحققوا نجاحاً في تدريس أنماط التصميم للطلاب. 

قد لاحظنا أن تدريس أنماط التصميم الذي يعتمد على نظام حقيقي بدلاً 
من الاعتماد على آمثلة صخيرة يحسّن من فهم الطلاب للتطوير المرتكز على 
أنماط التصميم. 
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إن استخدام النظم الكبيرة يزيد من الصعوبات في البداية» لكنه يزيد من 
تحفيز الطلاب وإبداعهم أيضاًء عند إدراك القدرة على فهم النظام وتوسيعه 
بمعرفة مفاهيمه. لقد استلمنا العديد من الحلول التي تخطت المهام المطلوبة 


الراجع 
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Conference on Object Oriented Programming Systems Languages and Ap- 
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(لچزو (لثاني 


الأساليب الحديثة 


4 


تأثير هندسة البرمجيات أدواتية التوحجه 


(Laura Bocçhi) yشتوہ لورا‎ 

باولو تشانکاري بني (Paolo Ciancarini)‏ 
روکو موریقي (iا†M016‏ 0 )R‏ 
فالنتیتا بریشو ق (Valentina Presuti)‏ 


4 1 المقدمة 

نتاقش في هذا الفصل تأثير هندسة البرمجيات أدواتية التوجه )۸08٤(‏ فى 
الحوسبة خدمية التوجه. نأخذ فى الاعتبار بعض الأفكار الأساسية للهيكلة خدمية 
التوجه (804) فى سياق التقنيات الأدواتية وذلك لتنسيق وتركيب الخدمات 
الشبكية وخدمات الويب. 

في العقد الماضي» تطورت شبكة الإنترنت تماشياً مع تطور خدمات 
الإنترنت المهيمنة لتصبح الأكثر شيوعاً والأوسع انتشاراً للظم المعلومات في 
العالم أجمع. أما صلب هذه الشبكة فهو النصوص المتشعبة ا×ها٣ممرط‏ التي 
تعرض بها الوثائق من قبل الأجهزة الخادمة ١إع۷٣عه‏ وبواسطتها تسترجع الأجهزة 
التابعة فاصعاء الوثائق بالاستعانة ببروتوكول نقل النصوص التشعبية ۸171۴ 
وتعرض من خلال واجهات الاستخدام الرسومية سهلة الاستخدام. نظراً إلى 
انتشارها الواسع» أصبح بالإمكان اعتماد شبكة الإنترنت كمنصة إطلاق للعديد 
من التطبيقات الديناميكية الموزعة سواء كانت تطبيقات صناعية أو أكاديمية"' . 


في الوقت ذاتهء من أهم الاتجاهات التي نلحظها اليوم في مجالات علوم 
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الحاسوب المختلفة إنشاء نظم معقدة مكونة من أجزاء أبسط وغير متجانسة 
وموزعة. فى حالة الأعمال الإلكترونية» لاحظنا اتجاهاً عاماً نحو الاستعانة 
بالمصادر الخار ج23 . والاستعانة بالمصادر الخارجية تعني التعاقد مع عاملين 
من خارج الشركة لتنفيذ مهام محددة بدلا من استخدام الموظفين. إن تطبيق هذا 
المصطلح على البنية التحتية لتكنولوجيا المعلومات لشركة ما يعني استغلال 
الموارد الخارجية من أجهزة وبرمجيات ودمجها بالنظام الداخلي للشركة. وعليه 
فقد تتكون البنية التحتية لتكنولوجيا المعلومات للشركة من الموارد الخارجية 
والشبكات والخدمات» إضافة إلى الأجزاء الداخلية أو المتوارئة. 

بالنسبة إلى العلوم الإلكترونيةء فإن ثمة حاجة كبيرة إلى الطاقة الحسابية 
ووسائل التخزين الكبيرة لإدارة كميات البياتات الكبيرة وذلك لدعم المهام 
والتجارب العلمية. منذ آواسط عقد التسعينيات من القرن الماضي» عنيت نماذج 
التصميم الشبكية الأولى بمعالجة هذه القضية. إن الحاجة إلى وسيط يعمل على 
تكامل الخدمات الديناميكية التي يتم تشغيلها ضمن منصات موزعة وغير 
متجانسة قادت إلى نشوء حلول مختلفة لكنها متداخلة في بعض أجزائها, 

من الصعوبة بمكان تحديد إطار عملي عام يتيح إدارة الخدمات بطريقة 
قياسية معيارية مستقلة. قد يحون الوسيط الذي يدعم التطبيقات الموزعة نقطة 
بداية فاعلة لتنفيذ إطار عملي كهذا. هذا ولم تعحقق التوافقية الكاملة بين 
منصات الوسائط المختلفة. هناك حاجة إلى إطار عملى خفيف يمكن أن 
يحقق التوافقية بين تقنيات الوسائط المختلفة المعروفة حالياًء وذلك لدعم 
الخدمات ضمن بنية مرجعية موحدة. 

تحاول كل من منهجية الهيكلية القائمة على النماذج (24 ۸“ والهيكلية 
خدمية التوجه آن تعالج هذه الاحتياجات. تبدأ الهيكلية القائمة على النماذج من 
الوحدات ومواصفاتهاء بيتما تبدأ الهيكلية القائمة على الخدمات من منهجية الحوسبة 
الموزعة التي تأخذ بالاعتبار الموارد البرمجية والخدمات المتاحة على الشبكة” . 


نحن نؤكد الأسباب التى تجعل من الأدوات (كادععهة) حلولاً ملائمة 
لتصميم وتطوير النظم خدمية التوجه عبر شبكة الإإنترنت والبنية التحتية للشبكية. 
فى هذا السياق» نركز على دور هندسة البرمجيات أدواتية التوجه (408۴) فى 
هيكلية خدمات الويب “)W84(‏ والشبكية. 

یتبتّى العديد من نطاقات التطبيقات المختلفة بروتوكولات الانترنت كأساس 
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للبنى التحتية للوسائط خدمية التوجه. مثلاًء تركز الأعمال الإلكترونية والعلوم 
الإلكترونية على منصات الوسائط التي تدمج الفكرة العامة للهيكلة خدمية التوجه 
(804) باستخدام البنى التحتية لاإنترنت والبروتوكولات الخاصة بهاء أي إنها 
تستخدم هيكلية خدمات الويب المستخدمة للأعمال الإلكترونية وتستخدم هيكلية 
خدمات الشبكية المفتوحة (0654) للعلوم الإلكترونية. 


تم تنظيم هذا الفصل على النحو الآتي: يقذَم القسم 2-4 للنظم الأدواتية 
وهندسة البرمجيات أدواثية التوجه» بينما يعرض القسم 3-4 لمحة عامة عن 
الحوسبة خدمية التوجه ۸۴ . یعرض ض القسم 44 قضايا تتعلق بالخدمات 
القائمة على النماذج 24 للأدوات الشبكية. يركز القسم 5-4 على التنسيق في 
هيكاية خدمات الويب. يناقش القسم 6-4 مسألة تحديد توصيف لتوفير آدوات 
في هيكلية خدمات الويب بطريقة قابلة للقراءة في مجال الاهتمام. أخيراً يعرض 
القسم 7-4 استنتاجاتنا مع الإشارة إلى الاتجاهات البحثية الممكنة في المستقبل. 


4 - 2 النظم الأدواتية وهندسة البرمجياث آدواتية الثوجه 

الأداة (امععة) هي نظام حاسوب مغلف يتواجد ضمن بيئة معيّنة بحيث 
يكون قادرا على التصرف الذاتي بمرونة في تلك البيثة وذلك بهدف تحقيق 
الأهداف التي صمم من أجلها»” . من هذا التعريف» يمكننا القول إن النظام 
الأداة هو طريقة للتفكير (استعارة برمجية) في النظم التي تتكون من كيانات 
فاعلة (آي من أدوات) وفي سلوكها المشترك. هذا وقد تكون النظم الأدواتية 
متباينة جد وقد تتضمن أجهزة ومعدات وبرمجيات ووثائق سارية المقعول 
وخدمات متناسقة وشبكات كاملة وأفراد. 

يكون استخدام «الأداة» فاعلاً أكثر ما يكون في بناء برمجيات خاصة بالنظم 
الشبكية المعقدة حيث لا يمكن أن تتوفر سيطرة شاملة. يعتمد قرار استخدام آداة 
واحدة أو عدة أدوات على مدى استخدام الوحدات وعلى الخاصية التي بيرغب 
في إحرازها عند تصميم النظم المعقدة. في هذا السياق» فإن الأداة هي آداة 
برمجة تعتمد على نموذج حوسبة محدد يرتبط بنماذج أخری کالوظائف الفرعية 
والوظائف المشاركة والإجراءات والعمليات والأنواع/ الكوائن. عموماً» يستخدم 
المصطلح البرمجي أداة اصعهةا بطرف عديدة: كعمليات/ برامج خفية دائمة أو 
شيفرة متغيرة أو روبوتات ذاتية التحكم أو أدوات ذكية (آي لا يوجد اتفاق حول 
ما يجعل منها أدوات ذكية). 
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في هذا الفصل» ما نعتيه بالأدوات البرمجية هو وحدات البتاء المنطقية 
للجيل القادم من الوسائط. إذ ستبني هذه الوسائط فوق الوسائط المستخدمة 
حالياً (مشال» 1ال ,۴78 ,00۸84) وستوفر تكاملاً في أثناء فترة التنفيذ من 
خلال الاكتشاف الديناميكي والتفاوض على الموارد. في هذا السياق» نعتبر أن 
هندسة البرمجيات أدواتية التوجه هي نظام يتعامل مع تصميم وتطوير التطبيقات 
الموزعة ذات الأدوات المتعددة' . 


تركز هندسة البرمجيات أدواتية التوجه على العلاقات بين المكرّنات 
وعلى هيكلية البرمجية ومنهجية التضميم المستخدمة لتطوير التطبيقات ذات 
الأدوات المتعددة. يتم تحديد أطر عمل ملائمة لبناء نظم متماسكة ذات بنية 
جيدة من مكرنات مفردة ولقهم التطبيقات المعقدة ذات الأدوات المتعددة 
وإدارتها وصيانتها. 

توفر هندسة البرمجيات أدواتية التوجه أساساً مفاهيمياً ذا جذور ممتدة 
في نطاقات المشكلة ذلك آن الأدوات في طبيعتها نظرية (تقليدية) في العديد 
من السياقات. ومن الحوافز الأخرى لهندسة البرمجيات أدواتية التوجه القدرة 
على زيادة إمكانيات التحويل إلى المواصفات المحلية للمستخدم وإخفاء 
تفاصيل مكونات التطبيقات التي تعمل من خلال شبكة الإنترنت والدعم 
القوي لإعادة استخدام التصاميم والبرامج القديمة. تتيح هندسة البرمجات 
أدواتية التوجه أيضاً استخدام مكؤنات النظم الفرعية كاملة (بما في ذلك 
آتماط التصميم والمكرنات الجاهزة التجارية)» أي الهيكليات المتعددة 
الأدوات والتفاعلات المرنة ما بينها (أطر عمل التطبيقات) إضافة إلى هيكليات 
التنسيق وبروتوكولات |أslja (Auction Protocols)‏ . 

بدءاً من المنهجية القائمة على هندسة البرمجيات أدواتية التوجه» يمكن 
تعريف دورة حياة البرمجية أدواتية التوجه كما يأتي : 

1. مواصفات متطلبات النظم الأدواتية 

2. تحليل المتطلبات . 


3. التصميم. 


4. كيفية تنفيذ هذه النظم . 
5. كيفية التحقق من أن النظم المنفذة تحقق المواصفات المطلوبة. 
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غالباً ما يتم توفير مواصفات المتطلبات من قبل المستخدم من ناحية 
السيتاريوهات المرغوب بها أو غير المرغوب بها. عادة ما تكون هذه المتطلبات 
غامضة ومتناقضة وغير كافية لتصميم النظام. إن الهدف من تحليل المتطلبات هو 
تحديد سلوك النظام الإجمالي المرغوب به. ويتم التركيز في هذه المرحلة على 
أهداف النظام الأساسية والأدوار التي يجب أن يقوم بها لحل المشكلة والموارد 
المتوفرة للحل والتفاعل مع المستخدمين والمتطلبات. تحديداًء يتم تحديد 
الأمور التي قد تختلف عن المتطلبات لتحقيق السلوك المتوقع وما لا يمكن 
قبول اختلافه. أما مرحلة التصميم فالهدف منها تحويل الأهداف والأدوار إلى 
أدوات واقعية» أي تحديد الأدوات التي ستنفذ أدواراً معينة. في هذه المرحلةء 
يتم تحديد أنواع الأدوات وعددهاء إضافة إلى تحويل التفاعلات المتقدمة إلى 
بروتوكولات تفاعل محددة؛ كما يتم في هذه المرحلة تحديد نوع الأداة لكل 
وظيفة عادية مطلوبة من النظام حتى يتم تنفيذ السلوكيات المتقدمة للنظام. في 
مرحلة التنفيذء يتم تحويل البروتوكولات والسلوكيات العادية إلى شيفرة برمجية. 
إضافة إلى ذلك يتم أخذ قرار بشأآن آلية ولغة ومضمون التواصل ولغة التنفيذ. 
أما بالنسبة إلى مرحلة التحقق» فيتم تلفيذ عملية لعرض دليل على تحقيق 
مواصفات المتطلبات. 

يبدو أن الأساليب أدواتية التوجه المستخدمة في تطوير البرمجيات التي تحتل 
حيّزاً كبيراً فى مجتمعات البسىع“'* ؟“* “ أصبحت نقطة بداية ذات معنى نحو 
تعريف مناهج تطوير البرمجيات خدمية التوجه. حتى نعرض هذا التطور الممكن» 
عرضنا باختصار منهجين من هذه المناهج » هما ونةG‏ ووەمه٣!‏ . 


منهجية هنەG‏ هي طريقة لهندسة النظم متعددة الأدوات تستخدم لوصف 
a» G36‏ 

تحديد تموذج للأآدوار والتفاعلات. أما مرحلة التصميم فهي المرحلة التي يتم 
فيها ترجمة هذه المفاهيم إلى نمافذج أدوات وخدمات ومعلومات. يبدو أن 
منهجية دنه تقتصر على النظم الصغيرة المستخدمة في الشركات الثابتة مع أن 
التطور الذي طرآ على هنهي يتيح نمذجة قوانين الشركة وتطبيقها على النظام. 

تتضمن منهجية “UOTropos‏ أساليب عديدة مختلفة لتحليل وتصميم 
المتطلبات. فهذه المنهجية تتيح نمذجة المستخدمين والأهداف المتعلقة بالأجهزة 
والبرامج والخطط والمواره والعلاقات والتبعيات بين ذلك كله. يبدو أن منهجية 
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همه" مصممة للنظم المغلقة بسبب نموذج هيكلية الأدوات الداخلية التي تتيح 
للمرء تعریفه. 

في القسم 7-4ء سنناقش كيف يمكن الانتقال من هندسة البرمجيات أدواتية 
التوجه 4۸08۴ إلى هندسة البرمجيات خدمية التوجه 808۴ من خلال 
الاستفادة من الأساليب أدواتية التوجه الملائمة لتصميم الهيكلة خدمية التوجه. 


4 - 3 تأثير الأدوات في الهيكليات خدمية التوجه 

الهيكلية خدمية التوجه 804 هى «مجموعة من المكرنات التى يمكن 
الاستعانة بهاء ويمكن نشر وصف الروابط بينها واكتشافها؛“ . أما الخدمات 
فهى كوائن خاصة بالشبكة يمكن عنونتها وهى ذات روابط معيارية محددة جيداً. 
لهذه الخدمات روابط غير معلنةء وهى متاحة للمستخدمين حيث تكون فى حالة 
خمول إلبى أن يصدر طلب الاستخدام. تتواصل الخدمات عن طريق 
بروتوكولات معيارية ويمكن الوصول لها واستخدامها من دون الحاجة إلى 
عمليات دمج. قد تستخدم الخدمة بعدة حالات مختلفة» ذلك آنها غير مرتبطة 
بسیاق محدد. 


ثمة تشابه جزئى بين الفكرة العامة للخدمة والفمكرة العامة للمكوؤن 
البرمجي. فالخدمات مقترنة بشكل طفيف كما هو الحال في المكرّناتء 
وكلاهما مصمم بمعزل عن السياق الذي يستخدمان فيه. فهما يميزان نفسيهما 
عن طريق المستوى النظري في كل منهما. تشتمل الهيكلية خدمية التوجه 80۸ 
على العديد من التنظيمات التي تتفاعل مع النظم المرتبطة من خلال شبكة» 
حيث لا يوجد مصمم واحد يضطلع بكل المعرفة والتحكم والملكيةء بل هي 
موزعة على عدة مصممين. الخدمات هي مكافئ معنوي للسلعةء وتملكها شركة 
معيّنةء وهي ذات دلالة وهدف بالنسبة إلى بعض عملاء الشركة. بهذا المعثى» 
تختلف الخدمات بطبيعتها كثيراً عن المكرنات. 


كما هو الأمر لمعظم الحالات المعروفة من الهيكليات خدمية التوجه» 
ونظراً إلى علاقتها مع سيناريوهات الأعمال الإلكترونية» يمكن وصف هيكلية 
للتوابع Clients)‏ (مثال على ذلك يتم شراء الخدمة من قبل التابع). 

تعرض هيكلية خدمات الشبكية المفعوحة خصائص ممائلة. لكن» 
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ونظراً إلى ارتباطها مع الشبكية وسيناريوهات تطبيقات العلوم الإلكترونية» زاد 
تركيزها على الكفاءة العامة والاستفادة المثلى من الموارد مقابل السلوك ذي 
المصالح الذاتية. 

يؤدي التنسيق والتركيب دوراً رئيساً في الهيكليات القائمة على مفهوم 
الخدمة. عادة ما تكون الخدمات تعاونية : فقد يتم استدعاؤها من قبل خدمات 
أخرى لتنفيذ مهمة معيّنة. إضافة إلى ذلك» تعتبر الهيكلة خدمية التوجه نظاماً 
شبكياً متعدد التنظيمات حيث لا يكون هناك مصمم واحد ذو معرفة وسيطرة 
وملكية كاملة. هذا ويمكن نشر الخدمات وتعديلها وإلغاؤها في آي وقت. بيد 
أن ذلك ينطوي على تأثير كبير نتيجة التغبير. أخيراًء تتميز الهيكلة خدمية التوجه 
بالانفتاح وعدم التيقن» ذلك أنه ليس من الممكن ترقع جميع الاحتمالات أو 
وصف جميع الاستجابات المحتملة للنظام مقدماً. لمعالجة القضايا المذكورة 
أعلاه» من المهم الاعتماد على : 


1. کائن برمجي ڏو قدرة على معالجة أمور التلسيق والت ركيب في نظام 
مفتوح يتسم بتأثر عالٍ بالتغيير. 

2. مواصفات قابلية قراءة البيانات المتبادلة بين الخدمات ودلالات 
الخدمات آلياً في مجال الاهتمام على وجه الخصوص. 


بالنسبة إلى البند الأول» تحقق عملية أتمته تنسيق وتركيب الخدمات فوائد 
مهمة من التقنيات المشتقة من سيناريوهات استخدام الأدوات (sئاصععة).‏ تم 
تعريف الأدوات على آنها «برامج تُشعْل بدلالات عالية بما فيه الكفاية لتشكل 
ارتباطات جديدة مع برامج أخرى بهدف تنفيذ الأعمال»* . 


الأدوات هي نموذج حوسبة موجه بالأهداف والأدوار. الأدوات فاعلة 
تحديدا لبتاء البرمجيات للنظم المعقدة المرتبطة بالشبكات حيث لا يوجد سيطرة 
شاملة. أما في النظم ذات الديناميكية العالية فيتطلب الأمر بعض الأحيان 
استخدام الأدوات للتركيب الذي لا يعتمد على معلومات مسبقة فحسب. في 
بعض الأحيان» يمكن معرفة المظاهر التي تحدد خصائص الخدمة في أثناء فترة 
التنفيذ فقط (مثال ذلك» عملية تحميل النظام) أو قد تكون هذه المظاهر حاسمة 
بالنسبة إلى خدمات العملاء. 


يتشابه سيناريو تركيب الأدوات الديناميكي المؤتمت لحل المشكلات 


123 


المرزعة ۲25 في النظم ذات الأدوات المتعددة» حيث تتوفر بعض مصادر 
المعرفة التي يجب أن ت تعثر على حلول مشتركة للمشكلة بطريقة غير مركزية. في 
ق حل المشكلات الموزعة» لا يكون کل مصدر من مصادر المعرفة قادرا 

تحقيق الحل بشكل مستقل؛ لذا يتم تحليل المشكلة إلى مهام فرعية 
تخ ال مصادر معرفة آخرين. 

اقترح ديفيس وسميث (طانص؟ ۵ه sاهص)"‏ بروتوكول الشبكة التعاقدي 
() الذي سن التفاوض على أساس طرح العطاءات لحل المشكلات 
الموزعة. التفاوض هو 2... نقاش يتبادل فيه الأطراف ذوو العلاقة 
المعلومات» بحيث يتوصلون إلى اتفاق في نهاية الأمره*“. : في آهم الحالات 
العامة» يكون التقاش عبارة عن عملية تتضمن أطرافاً قد يكونون بشراً أو آدرات 
برمجية. قامت مؤسسة الأدوات المادية الذكية 20(FIPA)‏ بوصف التفاعل بين 
الأدوات المشتركة في بروتوكول الشبكة التعاقدي عن طريق الخطوات الآتية : 

1. يرسل البادئ طلب الحصول على عرض. 


2. یقوم کل مشترك بعرض الطلبات المستلمة للحصول على العروض (من 
أطراف مختلفين) ويطرح عطاءات وفقاً لذلك. 

. يختار البادئ أفضل عطاءء ويمنح العقد للمشاركين القائمين للعطاء 
الأفضل ويرفض العطاءات الأخرى. 


يناقش المرجم أوجه التشابه بين بروتوكول الشبكة التعاقدي ۶×© 
(والمشكلة التي يعالجها) والمشكلات والحلول التي تعالجها هيكلية خدمات 
الويب W۷84‏ . 


بالنسبة إلى البند الثاني» من الأهمية بمكان الحصول على وصف لبعض 
النماذج بطريقة قابلة لقراءة البيانات المتبادلة آلياً وعلى الإمكانيات التي يوفرها 
جهاز الخادم 2ء۷ء8). في هذا السياقء من الأمور الرئيسة أن يتم تحديد أي 
مظاهر الخدمة قد عرفت في وصف النموذج بطريقة ملائمة (مثلاء وظيفة 
الخدمة» الخصائص غير الوظيفية والسلوكية) وما هى اللغة المُستخدمة للتعبير 
عن هذه المظاهر. في المرجہ*» نوقشت ثلاث طرق لوصف الخدمة: 
الوصف النصي (أي» يتم البحث نموذجياً عن طريق مطابقة الأنماط)ء الوصف 
الاستنباطي (أي» يتم التعبير عن خصائص الخدمة على هيئة الربط بين الخاصية 
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نین 


والقيمة)ء» والتوصيف. آما ميزة استخدام النوع الثالث بناءَ على التوصيفات 
فتکمن في القدرة على الاستدعاء (أي عدم وجود العثرة أمر سلبي» Absence)‏ 
False Negative‏ 0£)) والدقة والإحكام (أي (عدم وجود العثرة أمر إيجابي» 
((Absence of False Positive)‏ في عملية البحث. 


4 - 4 الهيكلية القائمة على النمافج ادمات الأدوات الشبكية 


يعود سبب التحسْن الفعلي الذي توفره الهيكلية خدمية التوجه في تطوير 
الوسائط إلى التوجه نحو النظم القائمة على خدمات الويب. تتيح خدمات الويب 
استخدام الوسيط لدعم الهيكليات خدمية التوجه مع بعض الخدمات ضحيفة 
التقارن التي من شأنها حل العديد من المشكلات التشغيل المتداخلة. 


يقة مماثلة» يمكن التعامل مع النظم الشبكية كوسيط ذي توجه خدمي 
ناشىئ باستخدام مكونات ضعيفة التقارن وتحويل التركيز إلى تشارك الموارد بدلا 
من التركيز على التنسيق البسيط عن بعد. أنشأت الشبكية كبيئة تشغيل ثابتة حيث 
يتم استخدام الموارد من قبل تخمين الدفعات بما في ذلك التفاعلات المنعدمة 
أو النادرة” . لقد تطور الأمر بحيث أصبحت البيئات أكثر ديناميكية حيث 
يمكن اكتشاف الموارد واستشمارها بعدة وسائل من وسائل الأدوات المضمنة في 
التطبيقات ذات الخدمات المكفة:22 , 


يتضمن هذا السيناريو أن إطار العمل لدمج الوسيط يتكون من التقارب بين 
تقنيات الشبكية وتقنيات خدمات الويب والوسيط الحالى فى الهيكلية القائمة 
على التموذج خدمي التوجه. في هذه العمليةء يمكن استخدام الهيكلية القائمة 
على النموذج لوضع التقتيات مع بعضها البعض» وعرض طريقة لتصميم برمجية 
ذات منصة مستقلة. تقود هذه الاعتبارات إلى نمذجة ذات منصة مستقلة 
لخدمات الشبكية" . تنص مسودة حديثة لوثيقة استخدام !لÎد|ö Globus Tookkit‏ 
4)4 على أن «يتم بناء التطبيق خدمي التوجه من خلال تركيب 
المكرّنات المحددة بواجهة الخدمة (وهی خدمات الويب حجسبه السيافق 
الحالى)). تجمع هله الجملة رۇية التقارب بین مکونات الوسائط وخدمات 
الويب وخدمات الشبكية في الهيكلية خدمية التوجه. 

الشبكية المفتوحة 0684 وإطار عملی موارد خدمات الريب 8۸۴ 
نموذجاً للنظم الشبكية يكون فيه كل شيء ممثلاً كخدمة: «كيان مخول من 
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شبكة الحاسوب يور بعض الإمكانيات من خلال تبادل الرسائل». هذا 
النموذج هو فعلياً هيكلية ذات توجه خدمي تدعم كل من التواصل عن بعد أو 
محليا لتوفير التوافقية بين المكونات. 

فى هيكلية خدمات الشبكية المفتوحةء تعرّف خدمات الشبكة بأنها خدمة 
ويب خاصة توذّر مجموعة من الواجهات الأساسية وتتبع تحولات محددة. أما 
إطار عمل موارد خدمات الويب فيحاول دمج منهجية هيكلية خدمات الشبكية 
المفتوحة بتقنيات الويب الدلالي. فهو يوسع آلية لغة وصف خدمات الويب 
D1‏ ما یتیح استخدام خدمات ويب وخدمات شبكية مميزة. إن وجود حالة 
هو موضوع مركزي لأنها تتيح تمييز حالة طلب خدمة من حالات الطلبات 
الأخرى. بهذه الطريقةء يمكن عرض هيكلية خدمات الشبكية المفتوحة كنظام 
موزع حيث يكون لكل طلب خدمة هوية فريدة خاصة به» كما يكون لكل طلب 
حالة معينة. 


إن التقارب بين الويب والشبكية المتحقق في إطار عمل موارد خدذمات 
الريب ۷5۸۴ له بعض التضميتات ذات المعنى بمستوى متقدم» تحديداً في 
الشبكية الدلالية“ وتصور خدمات الويب الدلالى“ فى هيكلية الخدمات 
الشبكية (684) الموضح من حيث هيكلية خدمات الشبكية المفتوسة* . 
تحاول الشبكية الدلالية إيجاد بيثة تركز على الإنترنت حيث تتشارك الموارد 
ويتم إدارتها اعتماداً على دلالات الربط البيني . تضيف خدمات الويب 
الدلالية دلالات إلى خدمات الويب مستغلة توصيف الخدمة الموصوفة فى لغة 
الترميز الخاصة بوكالة مشاريع أبحاث الدفاع المتقدمة "5۸1١1‏ أو لغة 
توصيف مصطلحات الويب ا0W‏ أو لغة النمذجة الموحدة”* . يهدف 
الباحثون فى مجال خدمات الويب الدلالى والشبيكة الدلالية إلى تطبيق تقنيات 
الويب الدلالى على خدمات الشبكة وذلك لإضافة دلالات للبرمجيات خدمية 
التوجه» التي تعتبر متطاباً أساسياً لتمكين الأدوات والسلوكيات المستقلة في 
الهيكليات خدمية التوجه (804). هذه الرؤية متعامدة مع التقارب بمستواه 
الأدنى بين الشبكة والإنترنت والمتحقق بواسطة الشبكية المفتوحة 0654 وإطار 
عملي موارد خدمات الريب ۷8۸۴. لدمج جميع التقنيات المبيّنة أعلاه في 


(«) بدأ برنامج إعداد لغة الترميز التابع لوكالة مشاريع أبحاث الدفاع المحقدمة 24۸۶۸ رسمياً عام 
0 والهدف من لغة الترميز هذه هو تطوير لغة وأدوات لتسهيل مفهوم الويب الدلالي (المترجم). 
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الشبكة الدلالية خدمية التوجه» يمكن استخدام الهيكلية القائمة على 
النماذج24 كموائم. تعتبر التحولات في النموذج إحدى أهم مزايا الهيكلية 
القائمة على النماذج. تستخدم مجموعة من القوانين والتقنيات لتحويل نموذج 
موصوف بلغة النمذجة الموحدة إلى نموذج آخر. في الهيكلية القائمة على 
النمافج» تمثل النماذج أجزاء من الوظائف آو بُنى أو سلوكيات النظام بدرجات 
مختلفة من التفاصيل. إن فصل طرق عرض النموذج المنتقاة عن طرق العرض 
المبسطة تسمح بإجراء التكبير - في العديد من النماذج البديلة لنفس وظائف 
النظام. توفر الهيكلية القائمة على النماذج منهجية ذات مستوى متقدم لتطوير 
الخدمات وتجيز إدارة دلالآات ودورة حياة تطبيقات الأعمال. كما آنها تتیح 
إجراء تكامل مع تقنيات أخرى وصيانة التطبيقات المعقدة التي تعمل ضمن 
هيكلية خفيفة. إضافة إلى ما تقدم» الهيكلية القائمة على النماذج في الهيكلية 
خدمية التوجه تخرّل المنهجية الموجهة بالخدمات لتطوير تطبيقات الأعمال . 
لذاء تعتبر الهيكلية القائمة على النماذج أداة مستقلة فاعلة كلغة النمذجة 
الموحدة» كما آنها أداة محايدة على نحو فعال للبرمجيات كائنية التوجه. 


في الختام» إن التقارب بين خدمات الشبكة والإنترنت هو الخطوة التالية 
فى تطوير هيكلية الخدمات الشبكية 684. فمن ناحيةء تبط خدمات الويب 
برمجة الشبكة» ومن ناحية أخرى فإنها تضيف بعض الآليات المفيدة جداً 
استقلالية المنصةء ما يسمح لنا بجمع خدمات الويب وخدمات الشبكة 
والأدوات معاً. 


4 - 5 تنسيق الأدوات والتزامن في هيكلية خدمات الويب 


الخدمات فى جوهرها هى كيانات عديمة الحالة. إضافة إلى ذلك» تتطلب 
العديد من سيناريوهات أعمال - أعمال إلى سلوك ذي حالة محددة وتعاونيةء 
وهذا ينطوي على تنسيق معقد. لذا فإنه يجب تحديد الترتيب بشكل مضبوط 
وبيان سبب الحاجة للعمليات الخدمية (على سبيل المثال: يتم الشراء بعد 
الدفع). في سيناريو خدمة الويب» ما من شيء يمنع تنسيق الخدمات على 
مستوى الشيفرة البرمجية للبرنامج. على أي حال» تركز معظم لغات التنسيق 
على إجراء فصل واضح بين التنسيق والحوسبةء وينظر إليها على أنها قضايا 
تتعلق بتصميم لغة متعامدة. ثمة استعارة شهيرة على هيثة معادلة بسيطة 
تستخدم تؤسس لهذه التعامدية على النحو الاتي: 
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البرنامج = الحوسبة + التنسيق (4.1) 

بناء على ذلك» وحسب هذه الاستعارة» يجب أن تتكون لغة البرمجة من 
مكونين متعامدين : مكرن التنسيق ومكوّن الحوسبة. هذا الفصل فعال من وجهة 
نظر هندسة البرمجيات: فالحفاظ على القضايا الخاصة بالتتسيق مفصولة عن 
القضايا المتعلقة بالحوسبة يسبب تفاعلاً على مستوى متقدم من الملخص» ما 
يعني تبسيط مهام البرمجة. هذا الفصل آمر حاسم في الهيكلة خدمية التوجه : في 
النظام ذي التقارن الضعيف» المتميز بتأثير الكبير للتغيير والمعيارية كميزة هامة. 
منذ عقد التسعينيات من القرن الماضي» آمكن التعبير عن منطق العمل وإدارته 
ة مستقلة عن البرنامج بواسطة نظام إدارة سير العمل المركزي .)۷M8(‏ 

في فر سياق هذا النظام» يمكن إعادة كتابة المعادلة (4.1) بالصورة الت <29 


سير العمل = اللشاطات + العمليات (4.2) 


حيث تكون الكيانات الأساسية في مخطط سير العمل عبارة عن النشاطات 
التي تنقذ وحدات العمل» بينما توظف العمليات لأداء التلسيق كالنشاطات. تتبع 
هذه المنهجية من قبل اللغات القائمة على ا۷ × الحالية (مثال ذلك لغات الترامن 
ولغات التصميم) التي تحاول توحيد إمكانية تنسيق الخدمة في هيكلية خدمات 
الويب ۷54 . هناك لغات مختلفة لتحديد مظاهر الخدمة المختلفة. على سبيل 
المثالء تصف آلية لغة وصف خدمات الويب ا۷582 الواجهة بينما تصف 
لغات التزامن والتصميم العملية. جميع هذه المعايير لا تلتقط دلالات الخدمة. 


4 - 6 منهجية توصيف هيكلية خدمات لویب 
الويب في سياق ما يعرف CU‏ الدلالي. تور خدمات الويب طريقة قياسية 


لتوافقية التطبيقات البرمجية التي يتم تشغيلها ضمن منصات وأطر عمل متنوعة. 
تم في رابطة الشبكة العالمية ea‏ تطوير مجموعة من التقنيات التي 


(#) منظمة 3٥‏ أو رابطة الشبكة العالية (سدناr‏ 0وو 01d We Web‏ هي أهم منظمة دولية 
لوضع المعابير لشبكة العالمية. تعمل منظمة ۷3٥‏ على إججاد ووضع قواعد ومواصفات ومعايير الأساسية وتطوير 
الحالية. معايير ©3 تقود شبكة الويب إلى الاعام» وتكون عادة سابقة الأوان من الممارسات الخحالية. هدفها هو 
تحسين التفاعل بين مسشخدمي الشبكة ووتوفير نماذج موحدة للناس للتعاون. تشارك ۷3٥0‏ أيضاً في الثربية 
والتوعية وتطوير البرجيات وهي بمثابة منتدى مفتوح لثاقشة الأمور المحعلغة بالويب (المترجم). 
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قادت هيكلية خدمات الويب إلى الجهد الكامن الكامل بطريقة نجاح مثل هذه 
التقنيات فى النمو فى القطاعين الصناعى والأكاديمي ولا يمكن استشمارها 
يهدف الويب الدلالي إلى إتاحة مشاركة المعرفة بين المصادر الموزعة 
والديناميكية غير المتجانسة. تمثل الأدوات طريقة طبيعية لتنفيذ هذه الأنواع من 
المهام. فکہا يۇكد المرجع” هذه الأدوات تناسب عملیات محتویات الويب 
ذات الدلالة. إضافة إلى ذلك» فهى تعرض قدرات اجتماعية واستقلالية. الأداة 
هي الجزء الأساسى فى البرمجية» تعمل على تنفيذ مهمة معيّنة» بينما الخدمة 
هى مورد يتميز بواسطة مجموعة تجريدية من الوظائف. 


في المرجع؟» تم شرح رؤية الويب الدلالي بهذا السيناريو» يمكن أن تنقذ 
الأدوات البرمجية التي تنتقل من صفحة إلى أخرى مهام معقدة للمستخدمين 
بسهولة. 


التوصيف هو المظهر الأساسي لإدراك رؤية الويب الدلالي. من وجهة 
النظر هذه؛ التوصيف هو عبارة عن وصف شكلي للمفاهيمية. فهي تعبر عن 
مدى من المفاهيم (نطاق معرفي معيّن) والعلاقات بينها والقيود المنطقية التي 
تحكم هذا النطاق. من الممكن تعريف التوصيف في الويب بمجموعة من 
اللغات كإطار عمل وصف المصادر (۸2۴) واه“ . في هذا 
السياق» يوفر التوصيف أساساً لتحديد مشكلة التقاط دلالات الخدمة. إن القدرة 
على فهم ما تؤديه الخدمة أمر حاسم للأداة البرمجية بهدف اكتشاف واختيار 
وتكوين الخدمات. بطريقة ممائلة» فمن الأهمية بمكان توفر القدرة على وصف 
والتقاط الأدوات التابعة لها وغيرها من الأدوات المطلوبة فى أثناء فترة التنفيذ» 
وفلك للتغلب على المشكلات التي لم تحدد مسبقاً. أجري العديد من الأبحاث 
لتحديد النقص فى الدلالات. هناك العديد من الجوانب الت يجب أن تراعی فى 
التوصيف المستخدم لحوسبة الخدمات؛ إذ يجب أن توفر آليات لتتيح الاكتشاف 
والتركيب والتزامن والتنسيق. على سبيل المثال» “0W1-8‏ هي توصيف 
خدمات الويب تخص ا0۷. فهدف هذا التوصيف تسهيل أتمتة اكتشاف وتنفيذ 
وتركيب خدمات الويب وعملياتها الداخلية. 


(#) لزيد من المعلومات› انظضر : > <hitp:/www.w3.org/TR/ow1-fea tures‏ „ 
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تم بناء 0۷1-5 بناءَ على ثلاثة مفاهيم جوهرية هي : 
© الملف الذى يلتقط ١‏ مات اللازمة لاكتشاف الخدمة والإعلان عنهاء 
و إعلان عنها 


© المعرفة الأساسية؛ التي توفر معلومات عن بروتوكولات النقل وكيفية 
التفاعل مع الخدمة. 

© النموذج» التي توفر وصفاً عن كيفية استخدام الخدمة. 

من الإسهامات الأخرى» توصيف نمذجة خدمة الويب 0٥8س“‏ الذي 
يوسع نطاق إطار عملي نمذجة خدمة الويب "W8۴١‏ . بتاء على إطار عملي 
نمذجة خدمة الويب» يحدد توصيف نمذجة خدمة الويب أربعة علاصر من 
الأعلى إلى الأسفل» والتى يجب أن تراعى بغية وصف خدماث الويب. هذه 
العناصر هي: التوصيفات وخدمات الويب والأهداف والوسطاء, بتحديد هذه 
العناصرء يوفر توصيف نمذجة خلمة الويب تراكيب لتحديد التوصيف ووصف 
إمكانية خدمات الويب (على سبيل المثال» الافتراضات والشروط المسبقة 
والشروط اللاحقة) والبينيات (كالتدسيق والتزامن) وذلك لوصف الأهداف التى 
التطابق المحتمل في العروض بین التو صيفات). في سياق الويب الدلاليء يقدم 
المرجع" آلية تصميم تتيح لنا التعامل مع تغير الخواص في التفاعل مع خدمات 
الويب. حقق هذا العمل آلية التصميم هذه في منصة تطوير خدمات الويب 


الدلالي 1۸88-111 (14) باستخدام توصيف نمذجة خدمة الويب” . 


على الرغم من أن 0۷1-5 وتوصيف نمذجة خدمة الويب تغطي قضايا 
كثيرة ذات صلة بدلالات خدمات الويبب إلا أن مثل هذه التوصيفات لا تراعي 
المشكلات المتعلقة بالجوانب الديتاميكية. على سبيل المثال» هذه التوصيفات لا 
تراعي كيفية التعامل مع الأوضاع التي لم تحدد مسبقاً (أي التنسيق الديناميكي). 
ترتبط الفكرة الأساسية للتنسيق الديناميكي بالنظم المفتوحة حيث لا تكون 
عمليات ومصادر النظم معلومة في فترة التصميم. في مثل هذا الوضع› يکوك من 
المفضل وجود آلية تتيح للعمليات (أو مجموعة مختارة منها) نقل الهدف من 
ورائها والحاجة إلى المصادر في أثناء فترة التنفيذ. تم اقتراح منهجية توصيف 
ممكنة لهذه المشكلة في المرجع”ء حيث حددت توصيفاً للتنسيق. أما المفاهيم 
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الرئيسة فهى: الأداة والعملية والمصدر الاعتمادية والعلاقة التشغيلية. تحديداًء 
عندما يتم تحديد النوع الفرعي لعملية مفهوم نشاط التنسيق. وهذا المفهوم 
بدوره هو عبارة عن تراكيب من النشاطات وبعضها يكون صغيراً (أي لا تتکون 
من نشاطات أخرى فرعية). تقارن مبادئ النشاط الصغير بمبادئ المعالجة في 
8. يتيح التوصيف التعبير عن عدد من مزايا النشاط التدسيقي كالموعد 
المبكر لبدء النشاط والفترة الزمنية المتوقعة لإنجازه والأداة التي يمكن أن تنفذ 
هذه التشاط. من خلال مفهوم المصدر (١٠إ٠0وء۸)‏ يمكن وصف طبيعة المصادر 
التي قد ثكون مطلوبة لتنفيذ النشاط. على سبيل المثال» قد يكون المصدر قابلاً 
للاستهلاك (أي أن استخدامه يقلل من مدى توافره) وقد يكون قابلاً للمشاركة (آي 
أنه يمكن أن تستخدمه أكثر من أداة واحدة في أي وقت). في نموذج الاعتمادية؛ 
يتم تحديد مفهوم العلاقة التنسيقية» التي قد تكون إما تنسيقاً إيجابياً آو سلبياً. على 
سبيل المثال» التنسيق السلبى هو علاقة تسبب بعض القشل إن حدثت» بينما 
التنسيق الإيجابي يجعل من الممكن تنفيذ نشاط آخر إن حدث. تستخدم العلاقة 
التشغيلية لحل العلاقات التنسيقية بين النشاطات. على سبيل المثالء إذا وجدت 
علاقة سلطة تعاقدية بين أداتين» فإن الأداة الأولى تأخذ آولویة أعلى من الأداة 
الثانية بسبب بعض القوانين المعرفة مسبقاً في السياق الذي تنتمي ي له. 


4 7 الاستتتاجات 


قمنا في هذا الفصل بإلقاء الضوء على الاهتمام المتزايد في التعامل مع كل 
من النظريات أدواتية التوجه والأساليب المتبعة لتنفيذها مع دعم لتطوير النظم 
الموزعة والمفتوحة التي توفرها الهيكلة -خدمية التوجه. 


بدا من الأساليب أدواتية التوجه المستخدمة في تطوير البرمجيات» يمكننا 
أن نفترض أعمال البحث التي تسعى إلى تحديد آساليب تطوير البرمجيات خدمية 
التوجه. حتی نمکن تفعیل أکثير الأساليب أدواتية تية التوجه نجاحاً في تصميم 
البرمجيات خدمية التوجهء يجب أن توفر مثل هذه الأساليب مرحلة لاستنباط 
كيفية ارتباط الوظائف - المعرفة حسب تموذج محدد للوظائف - مع كل خدمة. 
يجب أن تعطينا هذه الأساليب إمكانية تحديد العلاقات بين الوظائف التي تتضمنها 
الخدمات المعقدة. بهذه الطريقةء يتم بتاء هله الخدمات المعقدة فوف الخدمات 
الأخرى مباشرة بحيث ترتبط بالوظائف المعرفة في نموذج الوظائف. قد يكون 
هتاك مرحلة ثانية لنشر الخدمات ذات المرتبطة بالوظائف وقد تتضمن هذه 
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المرحلة من اختيار مكونات البرمجية لربطها مع كل وظيفة. قد تكون هذه الطريقة 
دورية تكرارية وتتيح إمكانية تحسين الخدمات ونموذج الوظائف. 

من توجهات البحث المهمة ما يختص بتجسير الهيكلية القائمة على 
الوحدات والشبكية وخدمات الويب الدلالية لتمكين تطوير التطبيقات فى الشبكة 
القائمة على النموذج ذي التوجة الخدمي. لهذا الغرض»› يجب أن یتم التحقق 
بعمق من مفهوم الخدمة حتى يتم استغلالها في تطوير البرمجيات الموزعة. 

أخيراً» تعتبر أعمال الأبحاث من الأمور المهمة المعنية بتحسين مفهوم 
الخدمة وذلك لدمج الأدوات والخدمات والدلالات. يعتبر وجود «حالة؟ تعبر 
عن الخدمة ودلالاتها قضية مركزية تحتاج إلى المزيد من التحقق» وذلك بهدف 
تعريفها تعريفاً ملائماً في نموذج التوجه الخدمي. 
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5 


اختبار البرمجيات كائنية التوجه 


(Leonardo Mariani) لپوناردو مارياني‎ 
(Mauro Pezzê)} ماريو بیتسې‎ 


5 1 المقدمة 

عملية تطوير البرمجيات هي عملية معقدة وعرضة للأخطاءء وقد تفشل في 
تحقيق أهداف الجودة إذا لم يتم التحقق من الخصائص المطلوبة بالطريقة 
الملائمة. لا يمكن إضافة الجودة كفكرة متأخرة» لكن يجب أن يتم العمل على 
تحسينها في أثناء عماية تطوير المنتج النهائي والتحقق منه. الاختبار والتحليل 
هما عنصرا عمليات تطوير البرمجيات التي تهدف إلى تحديد الأخطاء التي 
تحدث في أئناء التطويرء» كما تهدف إلى قياس مدى استعداد المنتج النهائي 
للاستخدام. تترجم عملية تطوير البرمجية احتياجات المستخدمين وتقييدها في 
مواصفات المتطلبات» كما إنها تحوّل المتطلبات إلى مواصفات الهيكلية 
والتصميم لإنتاج شيفرة برمجية يمكن أن تحدد احتياجات المستخدم. في كل 
خطوة» يعمل المطزرون على تشكيل الحلول المطلوبة عن طريق إضافة تفاصيل 
والاختيار من بين العديد من بدائل التصميم› في حين يعمل خبراء الجودة على 
التحقق من اتساق النماذج ومتعلقاتها وتوافقها مع الأفكار النظرية السابقة ومع 
احتیاجات المستخدم. 


تحدد منهجيات تطوير البرمجيات العوامل المشتركة بين عمليات تحديد 
إنتاجها في أثناء عملية التطوير وتقيّد خيارات أنشطة الاختبار والتحليل. 
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تم تطوير العديد من تقنيات الاختبار والتحليل في سياق المنهجيات 
الكلاسيكية وأساليب البرمجة» التي تفترض استخدام النماذج الإجرائية في 
البرمجية» بمعنى أنها تتعامل مع البرامج على أنها تحويل وظيفي من مدخلات 
إلى مخرجات. مثلاًء تعمل أساليب الاختبار الوظيفي المألوفة على العلاقة بين 
المدخلات والمخرجات كأسلوب تقسيم الفثات" أو الاختبار المرتكز على 
الفهرس» في حين تتخذ اختبارات تدفق البيانات والتحكم بها“ أسلوب 
البرمجة الإجرائية. 


يتميز التصميم كائني التوجه من خلال سلوكه المعتمد على حالته 
والتضمين )Eneapulation)‏ والتوارث وتعدد الأشكال والربط الديناميكى 
ويستغل التجانس والاستشناءات بشكل مكثف . تعدل هذه المزايا النماذج 
الإجرائية الكلاسيكية وتخفف من وطأة بعض مشكلات التصميم والتنفيذ 
المعروفة» لكنها تقدم نقاط ضعف جديدة تستدغي استخدام تقنيات جديدة 
للاختبار والتحليل. مثلاء الأنراع (9عدوه1١)‏ والكوائن تدفع إلى استخدام 
التضمين وإخفاء المعلومات» ما يقلل من العديد من المشكلات المعروفة 
المشتقة من الاستخدام المكثف للمعلومات غير المحلية في البرامج الإجرائية 
الكلاسيكية» في حين تؤجل عمليات التوارث وتعدد الأشكال من ربط الكوائن 
في آثناء فترة التشخيل»ء وقد تؤدي إلى قصور تعتمد على الربط الديناميكي بين 
الكوائن. لا تزال الأساليب الكلاسيكية مفيدة عند المستويات النظرية»ء عند 
التعامل مع المتطلبات المعبّر عنها بصورة مستقلة عن قرارات التصميم. لكن؛ 
لابد من إلحاق ذلك بتقنيات جديدة للتغلب على المشكلات الجديدة التى تدش 
عند استخدام مزايا التصميم كائني التوجه. ٠‏ 


5 - 2 تأثير التصميم كائني التوجه في الاختبار 

تؤثر المزايا كائنية التوجه في الاختبار والتحليل بطرق مختلفة. تتميز 
الأنواع والكوائن من خلال حالتهاء ولا تعتمد نتائج تلفيذ العمليات على قيم 
العوامل فحسب» كما في البرمجيات الإجرائية» لكنها تعتمد على حالة 
الكوائن. على سبيل المثالء إن تأئير استدعاء العملية انصسصهء للنرع امج 
المبين في الشكل 1-5 لا يعتمد على قيمة معامل المستودع ٥10ء4۲«‏ فحسب» 
بل يعتمد أيضاً على المحتويات الحالية للعربةء أي على حالة العربة. إن معظم 
منهجيات الاختبار الكلاسيكية تعتمد على العلاقات بين المدخلات 
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والمخرجات» ولا تأخذ في الاعتبار حالة البرنامج. على سبيل المثالء يتم 
اشتقاف سيناريوهات الاختبار لقيم مختلفة للعامل عو0uطع wa‏ للعملية انضصەco»‏ 
لكن لا تراعى المحتويات المختلفة للعربة» وهذا يؤدي إلى التخلص من بعض 
المشكلات المحتملة التي تعتمد على حالة الكائن. عند التعامل مع برمجية 
كائنية التوجهء علينا أن نراعى العمليات وتکاملها كما لو كانت إجراءاث» بل 
يجب أن نراعي الأنواع والكوائن أيضاًء كما أن علينا توسيع مجموعة التقنيات 
التي يمكن أن تتعامل مع معلومات حالة الكائن بفعالية. 


تصدر الأنواع والكوائن جزءاً من حالتها وسلوكها فقط» بينما يتم إخفاء 
تفاصيل التنفيذ عن الكوائن الخارجية. على سبيل المثال» النوع ٣ه‏ المبيّن في 
الشكل 1-5 يخفي ا الحقول صا وتفاصيل كص١٤٤!۲١٠«ںه‏ التي لا يمكن 
لكائن خارجي التوصل إليها إن التقنيات الكلاسيكية لإنشاء الأساسات والأجوبة 
الشافية تفترض وجود رؤية كاملة للشيفرة البرمجية. هذا ويمكن التخفيف من 
وطأة مشكلة الأساسات بكسر التضمين عن طريق تصدير المعلومات المخفية»› 
لكن ذلك لن يحل المشكلة. عند التعامل مع البرمجية كائنية التوجهء نحتاج إلى 
منهجيات جديدة تتعامل مع المعلومات المخقية بأمان. 


يمكن تحديد الآنواع عن طريق تخصيص آنواع أخرى. ترث الأنواع 
الفرعية خصائص الأنواع الأصلية وتضيف إليها مزايا أو تعدلها. يمكننا على 
سبيل المثال إنشاء النوع ١2۲٣ءإںءء8‏ عن طريق تخصيص النوع ١ة‏ المبين في 
الشكل 5 - 1. فالنوع Secure r‏ سیر ٹ خصائص النوع کما سیضیف 
بعض العمليات التي تتعامل مع صلاحيات تفويض المستخدم. إن إعادة 
الاستخدام المكثف للعمليات الموروئة يثير تساؤلات جديدة عن إعادة استخدام 
سيناريوهات الاختبار والتنفيذ الأمثل لها. العمليات (وفهطاءM)‏ المشتركة بين 
الأنواع الأصلية والأنواع الفرعية من دون وجود تعديلات مباشرة آو غير مباشرة 
يمكن أن يتم اختبارها مرة واحدة فقط» لکن يجب أن تكون تقنيات الاختبار 
قادرة على تحديد التفاعلات غير المباشرة وتجنب المشكلات التي قد تنتج من 
عات یر مرت ام م ا بطريقة ملائمة. 


4 


في البرامج كائنية التوجه» يمكن أن تغيّر المتغيرات نمطها ديناميكيا. 
نطاق التغييرات مقيّد بنمط أساسي ثابت ومعلن يعمل على ربط الأصناف 
الفعلية بحيث تصبح نمطا فرعياً تابعاً له. على سبيل المثالء المتغير ٣٣ر"‏ 
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المصرح عنه للنمط امه يمكن آن يرتبط ديناميكياً بالكوائن التي نمطها ٣و٣‏ 
بالإضافة إلى الكوائن ذات الأنماط الأخرى التى تخصص النمط ا٠ه٣٤‏ (على 
سبيل المثال» ه0ء«سهه8). يتبع الربط الديناميكي التسلسل الهرمي للتوارث› 
لكن لا تتسلقه: فالمتغيرات من النمط ٣ة٣٥٣س»؟‏ لا يمكن أن ترتبط 
بالكوائن من النمط اه٣.‏ بما أن المتغيرات يمكن أن تبدل نمطها ديناميكياًء 
فإنه يمكن ربط استدعاءات العملية في أئناء فترة التنفيذ فقط. عليك أن تراعي 
آن جميع حالات الربط الممكنة لكل استدعاء متعدد الأشكال يصبح غير 
عملي بسرعة» بما آن عدد مجموعات الربط قد ينمو بصورة أسَبّة. بناء على 
ذلك» علينا أن نختبر التقنيات التي تختار المجموعات الجزئية المناسبة 
لحالات الربط الممكنة. 


إضافة إلى خصائصها المميزة» تستفيد البرامج كائنية التوجه استفادة واسعة 
من الخصائص الإضافية التي لا تستغل جيداً فى التطبيقات الإجرائية : الشمولية 
والاستشناءات. ٠ ٠‏ 

معظم لغات البرمجة كائنية التوجه توفر أنواعاً عامة (أي أنواع 
منقذة بآنماط رمزية) ترتبط بأنماط أساسية عندما تكون الكوائن ذات الأنواع 
العامة متشابهة. على سبيل المثال»ء النوع hashtable‏ في الشكل 1-5 هو حالة 
من النوع العام Hash tale‏ الذي يعمل بمعاملین يمثلان المفتاح والقيمة اللذين 

یجب أن يکونا متمائثلین مع الأنماط الأساسية عند استخدامهما (مثلاً عصعا8 
Integers‏ في الشكل 1-5). يجب أن يراعى جميع التماثلات الممكنة عند 
اختبار الأنواع العامة وهذه قد تکون عديدة جداً. 


أما لغات البرمجية كائنية التوجه الحديثة فتوفر بناءات صريحة لمعالجة 
الحالات الاستثتائية والخاطئة. على سبيل المثالء في لغة الجافاء تستخدم ۷2ول 
try{...}catch (...) {...} fnally{...}‏ للتحكم بحجم التعليمات التي قد تنتج 
استشناءات - وتحدد معالج الاستشناءات المحلي. تضيف معالجات الاستشناءات 
تحكماً ضمنياًء ويمكن تفعيلها بصورة صريحة أو ضمنية في آثناء فترة التنفيذء 
على سبيل المثال» يمكن تفعيلها في حالات القسمة على صفر, مبدأ ذلك أن 
تفنيات الاختبار يمكن أن تأآخذ في الاعتبار جميع التنفيذات الضمنية والخاطئة 

عند إنشاء سيتاريوهات الاختبار. على كل» ينمو عدد التنفيذات الممكنة أَسَياً 


حتى بالنسبة إلى البرامج البسيطة. 
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public class Cart { 
private Hashtable < String, Integer> items: 
private int ruts TotIterns; 


itenıs = new Hashtable<String, Integer> Û; 
num Totltems = 0; 


} 


public void addItem(String itemld, Integer quantity) { 
itermıs.put(iternld, quantity): 
nun Totlterns#+=quantity: 


1 
2 
2 
3: 
4: pubiic Cart) { 
5: 
6 
۳ 
8 


} 


public void removeltem{String itemld) { 
Integer qt = getQuantity(iternld); 
if (qt != null) { 
num Totltems -= qt: 
items.remove(itemId); 
8 
} 


public void updateltern{ String ıtemlId, Irteger quantity) { 
if (getQuantity{itemld)} != null} { 
removelterm (itemId); 
addIterm(itemıld, quautity); 
} 
} 


public Integer getQuantity(String itemld) { return items.get{itemld}; } 
public int getNumTotltems() { returr nim T'otlitems; } 


public boolean comınit(Warehouse warehouse) { 
Enumeration< String> itemlds = items,keys(); 
if (litemlds has MoreEletnents{)) retarn true; 


warehouse. begin Transaction(); 


whilc(itemids,hasMorecElements()) { 
String id = itemılds,nextPlement{): 
if (Ilwarehouse.isA vailablelid, itemıs.get(id)))} { 
warehouse.abort Transactian(): 
reburrı false: 
} 
} 


itemlds = items.keys(): 


while(itemids.hasMoreElements()) { 
String id = itemlds.nex{Elemert( ); 
warehouse.removeid, items.geLid)); 


3 


items = new Hasbtable< String, Integer >(); 
num Totitema = Û; 


warehouse.commit Transaction{); 
return true; 


الشكل (5 - 1): مقتطفات من مثال العربة ٥1۲۲‏ البسيط بلغة البرجة ۷aو[‏ 
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5 3 تقنيات الاختبار القائمة على المواصفات 

تركز أهم تقنيات الاختبار القائمة على المواصفات المتوفرة حتى الآن 
للبرمجيات كائنية التوجه إما على مواصفات بيانية [تحديداً بلغة النمذجة 
الموحدة ا 0ل] أو على مواصفات أساسية [تحديداً مواصفات جبرية]" . 

توفر لغة النمذجة الموحدة العديد من لغات التوصيف والنمذجة التى 
تلتقط طرق عرض وخلاصات مختلفة في أثناء مراحل تحليل وتصميم 
المتطلبات المختلفة. حتى الآن» ركزت الأبحات التى تجرى على اختبارات 
النوع الداخلي بشكل أساسي على رسوم بيانية للحالة تحدد سلوك النوع المعتمد 
على حالته» في حين راعت الأبحاث التي أجريت على اختبار النوع الداخلي 
التماذج العديدة كالتسلسل والتعاون ومخططات النوع البيانية. 

تصف المواصفات الجبرية شارات ودلالات العملية» وتستخدم لاإنشاء 
سيناربوهات الاختبار أوتوماتيكياً. إن التقنية المعروفة باسم السيتاريوهات 
المرادفة لا تغير من عمليات التضمين وإخفاء المعلومات»ء ويمكن تكييفها 
لتوائم أنواع المواصفات الأخرى. 
5 - 4 اختبار النوع الداخلي بلغة النمذجة الموحدة ا0ا 

تصف مواصفات لغة النمذجة الموحدة (01) سلوك الأنواع القائمة على 
الحالة باستخدام رسوم بيانية للحالة؛ التي تستخدم أحياناً كآلات بيان الحالة 
محدودة وبسيطة (FSMs)‏ . تتکون آلة بيان الحالة المحدودة من مجموعة من 
الحالات ومجموعة من التحولات بين الحالات. تمثل الحالات مجموعة من قیم 
الخصائص التي ينتج منها ردود الأفعال نفسها التي تلتج من المحقزات التي 
تنتج من أي مراقب خارجي» بينما تمثل التحولات الأحداث التي يمكن أن 
تغيّر الحالة. تعنون التحولات باسم الحدث المرتبط باستدعاءات العملية أو 
المرتبط بالأعمال الداخلية. في الحالة الأولىء يحدث التحول عندما يتم تنفيذ 
الحمليةء بينما في الحالة الثانيةء يحدث التحول عند تنفيذ العمل الداخلي. 

تميّز آلات بيان الحالة المحدودة بواسطة الحالة الأولية التي تتوافق مع 
حالة الكائن الأولية ومجموعة من الحالات النهائية التى تمثل مجموعة الحالات 
التي يمكن عندها إنهاء التنفيذ. يدخل الكائن الجديد في حالته الأولية ويتطور 
حسب السلوك المحدد له مسبقاً إلى أن يصل إلى الحالة التهائية. 


142 


يبيّن الشكل 5 - 2 مثالا على آلة بيان الحالة محدودة تحدد عربة آمنة مضافة 
على تطبيق العربة الممثلة في الشكل 5 -1. نحن نفترض أن دلالات التحول 
المعرفة ضمنياً تنظم في حلقات ضمنية ذاتية"“ - أي أن النتائج غير المتوافقة مع 
آي من التحولات الصريحة تخرج من حالة معطاة. على سبيل المثال» يتوافق 
استدعاء العملية صع االله 0 في حالة ga notLogged‏ -حلقة ذاتية» آي إن عملية 
الاستدعاء لا تعدل الحالة. يقدم كل من لي (Lee)‏ ,اكيس “9(Yannakakis)‏ 
(sنلهوصصه¥)*“‏ التفاصيل الأساسية لالات تحديد الحالة المحدودة. 


ER 
SecureCarl) Rl E 
= O @ 
grees acdltern() updetetlem) 


الشكل (5- 2): بيان الحالة حلود وبسيط أو ع SecureCart‏ 


تفسير : الحالة الأولية مييّنة باللفلث» في حين أن الحالات النهائية مبيّئة بالدائرة المزدوجة. التحولات ذات 
العناوين المتتهية ب () تشير إلى استدهاء همليةء والعناوين العادية تشير إلى همليات داعظية. 


توسع النوع sا٣هطعماها؟‏ آلات تحديد الحالة المحدودة عن طريق زيادة 
عناوين التحولات لتمثيل الآثار الجانبية والحاميات (sل٣هدع)‏ وعن طريق تقديم 
آليات تركيب لنموذجة الحالات والتحولات بطريقة مدمجة. تكون الآثار الجانبية 
عبارة عن أعمال منفذة عند تفعيل التحولات - على سبيل المثال» تنفيذ عمليات 
الكوائن الخارجية أو تحديث المتغيرات المحلية. يبعنون تحؤّJ StatechaIt‏ 
بحدث مفرد وتسلسل فارغ من الأعمال. تفصل أسماء الأحداث عن الأعمال 
باستخدام العلامة (/). أما الحاميات فهي شروط مرتبطة بالتحولات. يمكن أن 
يتم تفعيل التحول إذا كانت قيمة الحامية خاصته «صحيح علا. يتم تحديد 
الحاميات بعد اسم الحدث من دون استخدام الأقواس المربعة. 

يبيّن الشكل 5 - 3 مواصفة مخطط الحالة اوطعماواS‏ الخاص ب 
Secure)‏ . تكون هذه المواصفة أكثر دقة من مواصفة آلة تحديد الحالة 
المحدودة المبيّنة في الشكل 5 - 2. بما إن مخطط الحالة ٤وطعماها8‏ يبيّن أن 
eure‏ يسبب تفاعلاً مع عد ۲عون» فإن الحالة المستهدفة تعتمد على 
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نتائج محاولات الدخول للنظام؛ ويمكن تنفيذ العمليتين ”ءا1للa‏ يupdateItem‏ 
إذا تم تعيين قيمة موجبة لكمية المتغير فقط. 


gelNumTolltems()‏ عربة سوق أمنة 
SecureCar1() [login Failed removeltem(O‏ 
userMng.checkCredentials) gotQuantity() commit) [empty cart)‏ 
return E‏ 
SecuroCart) login OKY‏ 
O > ete userMng,checkCredenlials] Logg ( sso OY‏ 
updato warehouse contont‏ 


addltem() [quantity > O) 


updaleitem() [quantity > O} 


الشكل (5 - 3) : مخطط الخالة للنو ع ٢٣04ء‏ بم 


تحدد آليات التركيب الحالات المركبة (أي الحالات التي تم الحصول 
عليها باتحاد عدة حالات) والبنى المتزامنة (أي الأجزاء الفرعية من الحالة التي 
یمکن أن تتطور بشکل متزامن). قام هاریل دیفید 14۲61 اا4 بوصف 
مخططات الحالة sاحهطتماها؟‏ بالتفصيل في بحفه . 
من الطرق البسيطة لإنشاء سيناريوهات الاختبار من آلة تحديد الحالة ۴M‏ 
ومخططات الحالة sاسهطعماها؟‏ أن يتم استدعاء جميع حالات تسلسل التحول 
الممكنة. هذا المعيار الذي يتوافق مع تغطية المسار في اختبارات الهيكلية بقود 
إلى العديد من سيناريوهات الاختبار بشكل لا نهائي وبسرعة. تحدد تقنيات 
الاختبار العملية مجموعات صغيرة من سيناربوهات الاختبار» لكنها تكون 
وثيقة الصلة ببعضها البعض» وذلك بالرجوع إلى الحالات والتحولات 
و اسا عات المترابطة من الحالات والتحولاتن ٠1<“‏ . أما المعابير الأكثر 
شيوعاً بالنسبة إلى آلة تحديد الحالة فهي شمول الحالات وشمول التحولات 
وشمول حلقة الحدود الداخلية. يتطلب شمول الحالة أن يتم اجتياز جميع 
الحالات مرة واحدة على الأفل. إن اجتياز جميع الحالات من دون اعتبار 
الأحداث التي يمكن أن تتطرأً على الحالة يعني اختيار مجموعات اختبار 
صغيرة» لكنها نادراً ما تكون كافية لأداء اختبار متمكن. على سبيل المثال» 
في حالة الاختبار الوحيدة الاتية : 
{TC1) SecureCart O, loginOK, commit Û)‏ 
يتم استعراض جميع حالات آلة تحديد الحالة ۴58 في الشكل 2-5» لکن 
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الأخطاء التي قل تکون موجودة في هله العمليات. 


يتطلب شمول الانتقال من حالة إلى أخرى أن يتم اجتياز جميع الانتقالات 
مرة واحدة على الأقل» بما فى ذلك الانتقالات الضمنيةء إذا كانت الدلالات 
المأخوذة فى الاعتبار تتطلب ذلك. شمول الانتقال بين الحالات يتضمن شمول 
الحالة؛ وهذإ يعني ضمان شمول جميع الحالات أيضاً. على سبيل المثال» حالة 
الاختبار الوحيدة 1٥1‏ الكافية لضمان شمول الحالة» ليس من ضمان لشمول 
الانتقال بین الحالات في آلة تحديد الحالة في الشكل 2-5. نحتاج هتا إلى 
سيناريوهات اختبار إضافية» كما في المثال الآتي 0 


(TC2) SecureCart Û, loginOK, addItem (0, removeItem Û0, 
(commit Û 

(TC3) SecureCart Û, loginFailed, addItem 0, 
(getQuantity Û), updateltem (), removeItem Û, 
(getNumTotItems Û), SecureCart Û, loginOK, 
(addItem Û, updateltem Û, commit Û 

(TCA SecureCart Û, loginOK, addItem Û, getQuantity Û, 
getNumTotItems Û0, commit Û 


إن تغطية الانتقال من شأنه أن يحسّن من تغطية الحالةء لكنه قد يغفل عن 
السلوكيات غير الصحيحة التي تعتمد على عمليات التنفيذ المتكررة. 

يتطلب تغطية حلقة الحدود الداخلية وجود مسارات بسيطة لاستعمالها. 
والمسار البسيط هو المسار الذي يبدأ من حالة أولية ويتتهي بحالة نهائية ويجتاز 
جميع الحالات مرة واحدة فقط. أما الحلقة فهي المسار الذي يبدا وينتهي بنفس 
الحالة. يمكن أن تجتاز الحلقة عدة مرات فى عملية تنفيذ واحدة. أما تغطية 
حلقة الحدود الداخلية فيتطلب الأمر اجتياز المسار البسيط مرة واحدة على 
الأقل» لكن يتطلب اجتياز كل حلقة عدداً من المرات مساوياً للحدَ الأدتى 
والحد الأعلى. كما يتطلب ذلك اجتياز الحلقة عدداً من المرات يتراوح بين 


(1) طالا أن تسجيل الخحالة يمشل النتائج الممكنة فقط لمحاولات الدخول» لا تأخذ في الحسبان الانتقالات 
الضمئية لهذه الحالة. 
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الحد الأدنى والحد الأعلى. يضمن تغطية مسار الحدود الداخلية تغطية أفضل 
من المعايير السابقة بنفس تكلفة مجموعات الاختبار الأكبر حجماً. 

إذا أخذنا في الاعتبار آلة تحديد الحالة ۴8M‏ في الشكل 2-5 وقيّدنا عدد 
مرات تكرار الحلقة إلى 3ء فإننا نحقق تغطية حلقة الحدود الداخلية عن طريق 


(TC5) SecureCart Û, loginOK, addItem Û, addIterm (0, addIterm Û, cornrnit Û 
(TC6) SecureCart Û, loginFailed, SecureCart Û, loginFailed, SecureCart Û0, lo- 
ginFailed, 
SecureCart Û, loginOK, addItem Û0, getQuantity Û, getQuantity Û, get- 
Quantity Û, commit Û 


قام العديد > من الباحثين بتحديد معايير إضافية لمخططات الحالة 
عاعوطتاهاS‏ وبعض المتغيرات الأخرى الخاصة بآلة تحديد الحالة ۴8M‏ کمر وای 
الإدخال والإخراج ذات التشغيل الذاتي” * ٣٠4‏ ٠اسه‏ 1/0. وهناك طريقة 
على وجه الخصوص وهي «# التي نتج سيناريوهات اختبار بتوفر لیات 
عن السلوك المراقب" . تزيد هذه الطريقة من تغطية التحول عن طريق اعثماد 
مفهوم متسلسلات التمييز وتطلّب تغطية متسلسلة تمييز واحدة على الأقل لكل 
حالة. أما متسلسلة التمييز للوضع فهي تسلسل يعمل على تمييز حالة معيّنة من 
غيرها من الحالات في ميناء إدخال/ إخراج ذاتي التشغيل عن طريق إنتاج مخرج 
واضح ومميز. إل تغطية الانتقال من حالة إلى آخرى يضمن تغطية جميع 
الأحداث لجميع الحالات. آما تخطية تسلسل التمييز فيضمن مراقبة التأثيرات 
المختلفة من المخرجات الخارجية. يتم الحصول على سيتاريوهات الاختبار عن 
طريق وضع التسلسلات مع ! بعضها البعض» بتسلسل يضمن تغطية الانتقال 
بمتسلسلات التمييز. مثلاء يمكن الحصول على متسلسلات التمييز لمخطط 
الحالة احوطءءاةا5 الموضح في الشكل 5 - 3 عن طريق استغلال المخرجات 
والإشارات الصادرة عن العمليتين 2۲٣u۲۶ءء8$ commit‏ 0 هذا وقد تم شرح 
متغيرات وتفاصيل الطريقة م۷ في المرجعين"' وة'. 

إذا تضمن مخطط llkÛİlة Statechart‏ أوضاع حماية» يمكننا أن نطبق 
معايير تغطية مشروطة ومتفرعة على تلك الحمايات. على سبيل المثال» يمكننا 
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أن نطبق معيار القرار المشروط المعدل )M٣/2٥(‏ عن طريق جعل كل فقرة 
في الحمايات تقييم حالات الصح والخطاً في أآثناء تحديد النتيجة النهائية 
للتعبير كاملا“ . إن منطقية هذا المعيار هي آن كل فقرة يجب أن تختبر على 
حدة» وذلك لتجنب تأثيرات الحجب بين الفقرات المختلفة. يتضمن هذا 
المعيار سيناريوهات الاختبار التي تنتهل شروط الحماية. وهذه الحالات مفيدة 
للتحقق من كيفية استجابة الكائن المستهدف للمحفزات غير المقبولة بسبب 
قيم بيانات معبّنة. 


على سبيل المثالء يتطلب المعيار المطبق على مخطط |لllة Statechart‏ 

فى الشكل 5 - 3 سيناريوهات اختبار تعمل على تنفيذ (أ) العملية 02 u۲ءمة‏ 

0 عند نجاح أو فشل عملية الدخول»ء و(ب) العملية انصصهء () عندما تكون 

العربة فارغة أو غير فارغة» و(ج) lanallتٽ updateltem, © addItem‏ 0( مع 

الكميات الموجبة وغير الموجبة. ! ذا تم تحديد الحمايات بلغة قيود الكائن ا٣٤0‏ 
فإنه يمكن إنتاج سيناريوهات الاختبار بطريقة شبه آلية . 


يمكن التعبير عن دلالات آلیات تكوين مخطط الحالة من حيث مخططات 
حالة واتوطعماةاS‏ بسيطة» وبذا يمكن اشتقاق سيناريوهات الاختبار بالرجوع إلى 
مخططات الحالة الممهدة كما ورد في إءلمز8 . تسبب عملية التمهيد تحلل 
التسلسل الهرمي والبتى المتزامنة إلى مخططات حالة كبيرة ممهدة تمثل كافة 
السلوكيات الممكنة. 

تتضمن العربة فى الشكل 5 - 1 خللاًء ذلك أنه إذا استدعيت العملية 
صها1فهه لإضافة عنصر موجود مسبقاً في العربةء فإنه سيتم تجاوز الكمية 
المخزنة في eاabاashط»‏ بينما تزيد قيمة متغير الحالة sصعاآ1اه٣سست‏ وبذا 
تصبح العناصر الموجودة فى العربة والكمية المسجلة في num Totem‏ 
مختلفة. على سبيل المثالء إن استدعاء العمليٿين (addIterm ("Java Book",1‏ 
وBook",2 )ad1tem )"Java‏ وتنفيذهما على عربة فارغة ينتج مله عربة تحتوي 
علی نسختین من Book"‏ aہھل"‏ بینما یسجل ٣٤ا]٤٥‏ ںہ ثلاث نسخ. هذاء 
ويمكن كشف هذا الخلل بتنفيذ العملية ”الله مرتین على الأقل بنفس 
العنصرء ومن ثم تنفيذ العملية ۳ءا]٠ه Nu‏ )مع (). قد تتحقق تغطية الحالة 
والانتقال بمجموعات اختبار ہ١‏ تتضمن إعادة استدعاء العمليةء وبهذا له يمکن 
كشف الخلل» بينما تكون احتمالية كشف الخلل أكبر في تغطية حلاقة الحدود 


147 


الداخلية لأنها تتطلب وجود سیناریوهات اختبار تتضمن تنفيذ العملية صع)!للج 
علة مرات. 


5 5 اختبار النوع الداخلي في لغة النمذجة الموحدة 

تستخدم مخططات الحالة (sامةطءة)5)‏ بشكل أساسي لوصف سلوك 
النوع الداخلي» لكن تنفيذ الأحداث والعملية المتعلقة بالانتقال بين الحالات 
يوفر معلومات عن النوع الداخلي أيضاً. توفر لغة النمذجة الموحدة بعض 
اللغات الأخرى لوصف العلاقات في النوع الداخلي : فالمخططات البيانية للنوع 
والكائن تصف بنية النظام بشكل ثابت» بينما تصف مخططات التسلسل 
والتشارك التفاعلات الديناميكية. هذا ولم تكن مخططات لغة النمذجة الموحدة 
كسيناريوهات الاستخدام والحزم ومخططات الأنشطة محط اهتمام الباحثين من 
حیث اختبارهاء 


لاشتقاق سيناريوهات اختبار النوع الداخلي من مخططات الحالة 
(sاarطStatec).‏ علينا أن نفسر التعليقات الخاصة بعمليات الانتقال وتحديد 
دلالاتها. لقد صيغت عمليات تنفيذ الأحداث والعمليات التي تعنون الانتقالات 
في كا٣ةطته٤ها5‏ بطرق عديدة. فالإبلاغ عن مخطط الحالة يحدد العناوين 
باستخدام عمليات الاتصال المتسلسلة 8۴ . تعطى العناوين كمتسلسلات 
لإجراءات الاتصال على النحو الآتي : 


۷1 eءموطء_‏ تمثل عملية إدخال متزامن؛ المتغير اعصصهطء هو اسم 
القناة التي تدعم الاتصال» آما المتغير لة۷ها فهو اسم 

رمزي للمُدخل المستلم من القناة. 
nne!!t1طc_”‏ يمثل عملية إخراج متزامن؛ المتغير اعصصةطء هو اسم 
القناة التي تدعم الاتصال» أما المتغير لة ۷اه فهو اسم 

رمزي للمخرج المرسل من القناة. 
تكون عمليات الإدخال/ الإخراج (1/0) المتزامنة التي تعود إلى القناة 
نفسها متقارنة وذلك لنمذجة الاتصال بين كائنين. على سبيل المثالء العملية 
Secure‏ في الشكل 5 - 3 يمكن أن تكون مرفقة بتسلسل عمليات الإخراج 
lyد-=ة_ ^_userAuthChannel!credential_userAuthChannel?result Jl‏ التي 
تتطابق مع عمليات الإدخاJ _userAuthChannel? credential‏ والإخراج 
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^_userAuthChannel?result‏ المنمَڭة ة من قبل مدير المستخدم المخول»ء وذلك 
لنمذجة الاتصال بين الكائنين المتطلبين لتخويل المستخدم. 

يمکن اشتقاق سيناريوهات الاختبار من مخططات |llkdJة (Statecharts)‏ 
للاتصال بواسطة (أ) اختيار مجموعة متكاملة من الكوائن التي یجب آن یتم 
اختبارهاء (ب) تكوين مخططات حالة للاتصال أوتوماتيكياً في مخطط حالة 
واحدة يمثل سلوك التظام الفرعي المتكامل» و(ج) اشتقاق سيناريوهات الاختبار 
من مخطط الحالة المتكامل مع التقنيات التقليدية. 


حالات مخطط الحالة المكوّن هي عبارة عن المنتج الديكارتي لحالات 
مخطط الحالة الأصلى. إن حالات الانتقال من حالة إلى أخرى غير المشمولة فى 
الاتصال تربط جميع الحالات التي تعمم الحالات الأصلية المرتبطة بالائتقالاتء 
في حين يتم دمج الانتقالات في عملية انتقال واحدة تكون بديلة عن آزواج 
الانتقالات المتضمنة في الاتصال. يعرض كل من هارتہان ۸۲۲٣4٣ ”٣(‏ 
وإیموبیردور (Imoberdorf) J‏ ومينسينخر 22(Meisin ger)‏ خوارزمية تركکیب 
تزايدية لتكوين مجموعات من مخططات الحالة. تستتد الخوارزمية إلى مساعد 
على الكشف لاختيار مخططات الحالة التى يجب أن تدخل فى التركيب وذلك 
بشكل تزايدي. يهدف الكشف إلى تقليل حجم مخططات الحالة لتصبح متوسطة 
الحجم وذلك للحد من تأثير تفكك الحالة. 

تكمل مخططات التسلسل والتشارك مواصفات مخططات الحالة من خلال 
وصف التسلسل التفاعلي النموذجي بين الكوائن. يبيّن الشكل 5 - 4 مخططاً 
تسلسليا يمثل تفاعلاً نموذجیاً بي بين العربة الآمنة ومستخدم بصلاحیات مدير 
ومستودع ووکيل خارجي. يبيّن المخطط حالة نجاح عملية الدخول إلى النظام 
متبوعة بإصدار طلب لمادتين. 

تشتق مخططات التسلسل عادة من المتطلبات ومواصفات النظام التي یتم 
تحديدها في مراحل المشروع الأولى» وذلك لنمذجة السيناريوهات التي يمكن 
تنفيذها والتحقق من صحتها في النظام المستهدف (عادة ما تور مخططات 
التسلسل تفاصيل عن تسلسل عمليات الدمج المتوقعة وقيم البيانات التي يجب 
تبادلها)» بذا فهي تمثل حالات الاختبار المحتملة. على سبيل المثال»؛ 
يخصص مخطط التسلسل في الشكل 5 - 4 أن العربة يجب آن تستدعي 
العملية عاطوانهر84ا مرتين ومن ثم العملية ١۷٥”ء٠‏ مرتين على المستودع. في 
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الحالتين؛ بيجب أن يمرر الاستدعاء الأول المعاملات ١01ل0ء»‏ و22٩ء‏ بينما 
پجب آن پعرر الاستدعاء الثاني المعاملات tcod02‏ و12. 


سس )س 
new SecureCart{user, cred) 1‏ | 
1 
login(user, cred) 1‏ 
1 
: اد ا 
1 
i‏ 1 
1 1 
1 1 
۱ : 
addilem("cod01",2) ۱ 1‏ 
1 أ 
addltem("cod02",1) 1 : 1‏ 
1 1 + 
أ 1 1 commit)‏ 
1 1 ل 
beginTransaction() 1‏ 
]1 4 
isAvailable("cod01",2) 1‏ 
true‏ 
OE OSE) ARS 1‏ 
isAvailable("cod02",1} 1‏ 
7iê 5‏ 
چ ت 
remove{"cod01",2)‏ 
٤‏ 
‌ 
remove("tod02",1)} ۲‏ 
1 
commitTransaction() 11‏ 
true 1 :‏ 
س ادا 
1 ا 1 
١ ۱‏ [ 


الشكل (4-5): مخطط تسلسل ينمذج عملية شراء مادتين من العربة الآمنة 


تشتق مخططات التسلسل عادة في المراحل الأولى من عملية التطوير› 
وبذا فهي نادراً ما تكون قابلة للتنفيذ مباشرة» وذلك لأنها تفعقد لتفاصيل 
التنفيذ. على سبيل المثال» لا بحدد مخطط التسلسل في الشكل 5 - 4 أن تنفيذ 
العملية عاطهانة۷هوة للمستودع تكون «صح؟ فقط إذا كانت المادة والكمية 
المطلوبة متوفرتين في قاعدة البيانات. لتنفيذ سيناريو الاختبار المرتبطة بهذا 
المخطط يجب أن يجهز مهندسو الاختبار قاعدة البيانات بطريقة ملائمة. 
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يشكل عام» لا بمكن إضافة التفاصيل المفقودة آوتوماتيكياًء لكن هناك 
أدواث تعمل على إنتاج شيفرة تحويل العوامل لعنفيذ مخططات الشسلسل 
ومراقبة سلوك التطبيقات المرتبطة في فترة التنفيذ» وذلك للعحقق ممًا إذا 
كانت عمليات التنفيذ تلبّي السلوك المحدد في مخططات التسلسل*"؛ ومن 
هذه الأدرات 865116٤‏ . 


أما مخططات التشارك فتوفر طريقة بديلة لوصف تسلسل التفاعلات بين 
الكوائن. في هذه المخططات» ترتبط الكوائن بخطوط مباشرة تمشل حالات 
الاتصال. يتم التفاعل بين العمليات المستدعاة. پعنون كل خط بالعملية المرتبطة به 
أو برسالة مع رقم يشير إلى ترتيب الاتصال. هذا وقد تمل مخططات العشارك 
المتغيرات المتبادلة في أثناء الحوسبة. بين الشكل 5 - 5 مثالاً على مخطط تشاركي 
بمثل التفاعلات supplierManagery orderingSystemy backend Controller jq‏ 
warehouse,‏ و noneyAdmin‏ لإکمال طلب المواد بنجاح. 


2: order Product{ supplier. prod uct quantity) —# 


lenamgsysem) Û 


order produc, quanlrty} =* 


MUb'Anpo1d'Janddns}etur ASANO POEUIIS 3êf= ewl}. (2 —* 


a 
& 
ك‎ 
چ‎ 
3 
2 
3 
8 
و‎ 


# 3.2:inOrdar{producl,quantly, ime} 


الشكل (5- 5): مخطط تشارك يمثل طلب منج جديد 


يعمل beken oni‏ على استخلاص المورد الاقتراضي للمنتج 
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المطلوب» حيث يطلب المنتج بفعالية عن طريق إصدار طلب ل صاور8عماإءلإه 
الذي يستخلص وقٽث التسليم المتوقع ویعلم المستودع عن الطلب قيد الانتظار› 
و أخير | يقوم backend Controller‏ بإشعار money Admin‏ لإاكمال معالچة الطلب. 

تعمل مخططات التشارك - كما هو الحال فى مخططات التسلسل - على 
نمذجة متسلسلات التفاعل النموذجية» وتشير إلى سيناريوهات الاختبار. يحدد 
كل من عبد الرازق (kن#وعںلطه)‏ وأوفوت (ا0۴۴0)“ منهجية اختبار بسيطة 


يقترح کل من آندروز (WءلصA)‏ وفرانس (۶٥د۵إ۴)‏ وغوش (طومط6) 
وكريغ (وعنهء٣)‏ معايير بديلة بتاءَ على الظروف التي قد تحدث في 
المخططات: فهم يتطلبون تغطية جميع الظروف (تغطية ظرفية) وجميع 
الشروط (تغخطية إسنادية كاملة) وكل رسالة على حدة (تغطية كل رسالة في 
حالة ربط) والمسارات الكاملة التي تمثل مخططات التشارك (تغطية مسارات 
الرسالة) والرسائل التي تتبادل مجموعات بتغيير حجم المجموعات المتبادلة 
(تغطية المجموعات) . 

تحدد مخططات النوع والكائن العلاقات بين الأنواع والكرائن. العلاقات 
المشتركة الممثلة في مخططات النوع والكائن هي () الاتحادات التي تمثل 
الروابط بين الأنواع» (ب) التخصيص الذي يمشل الأنواع المتوارثة من آنواع 
آخری» و(ج) التراكيب التي تمشل الكوائن التي يحصل عليها من التجميع. يبن 
الشكل 5 _ 6 مثالا على مخطط نوع لنظام تسوّق من خلال الإنترنت. 

يشتق أندروز والآخرون سيناريوهات الاختبار من مخططات التوع عن 

يق تغطية العناصر الهيكلية. فهم يحددون ثلائة معايير رئيسة: تغطية الارتباط 
النهائي التعددية وتغطية التعميم وتغطية سمة النوع. تتطلب تغطية الارتباط 
النهائي التعددية سيناريوهات اختبار تمائل كل ارتباط صفري ووسيط والحد 
الأقصى من المرات. أما فى حالة تعدد الروابط فيتطلب المعيار سيناريوهات 
اختبار للجداء الديكارتي للسيتاريوهات المفردة. 


على سبيل المثال» يمكن تغطية الارتباط بين العربة ه٣‏ والمستودع 
Warehouse‏ في الشكل 5 - 6 بواسطة ثلائة سيناريوهات اختبار. يتماثل 


السيناريو الأول مع مستودع من دون أي ارتباط مع العربة (الحالات الصفرية)» 
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يتمائل السيناريو الثاني مع المستودع وعربتين (حالات الكميات المثوسطة)» 
ویتماثل السيناريو الثالث ص همسٿودغ و100 عربة (الحالات القصورى). 


1 MoneyAdminisiralion 


l+orderedP rahictfir supplierld ' String, in produclld : Stung, In quantity : inl} 
ا‎ 


SupplierManager 
11 کک ا‎ 
+ertral!DefaullSuppliain peoducild : Strang} ! String 


BackEmiCinirolle 
maneyên. hipnayAdnyin istrallarn 
«Supper ! SuppRetAanager 
-ordenng . Qrderingêyatem 
anartin podzcild : Slring, ın quanti ty ° im] 
+ 


+gefEstmatedDeliyeryTimefir suppiarld ; String, n prûducthd = String, irr qaantity ; ind] : ant 
+0 


OrderingSyslerm 
-auppiier : Suppligr Manager 
lrarehoişe : Watahguse 

rorderProdurtfin supplied: Srirg, in product : SIring,. in quantity ; in1} 


. اا 
1 


1 

Car 
ore e Warehauşe 
numTotltems : kl — 
sadcltamin femld , Siring, î qUartity + inl] arehouseld ; DBCenmnerbyn 
+ pGaleftamfîn tarmild . Sirirg, in quartily . inl} 
+removellemfn tamdd : SIinng} 
+pelduantitylir lemld Strg} int 
stû miii warêhouse ; Yarê hist) ; boo 
+getumTotlerna{} : int 


abort Transactontjf) 
4sAyailablefîn terik : Slring. in quantity : inl} : Bool 
HEmkvelin tamid : Ştring, in qyanlty : nt} 


LnerManager 


Lserbing : UserManager -uprDB : DBonnec lian 
+Securebartlln ger ; Sing, in cred : Credential) : Spcureanl 4  |teheckCredenkalsin user : Sfring, ın çrelantals : Credeniial) : boc 


الشكل (5 - 6): خطط نوع لنظام تسؤق 


بثطلب معيار التعميم سيناريوهات اخثبار تماثل كل نمط فرعي من الأنماط 
مرة واحدة على الأقل. پختبر هذا المعيار إمكانية استبدال نمط كائن بآي من 
الأنماط الفرعية التايعة له. على سبيل المثال» يمكن تططية التعميم بين ا٣ة)‏ 
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وart Secure)‏ فى الشكل 5 ۔- 6 بسیناریوهی اختبار» بحیٹث يماثل السيتاريو 
الأول ویستخدم a‏ بينما یماثل السيناريو الثاني وپستخدم SecureCart‏ .„ 


يتطلب معيار سمة النوع سيناريوهات احتبار تعمل على جميع مجاميع 
سمات الحالات لكل نوع على حدة. يمكن الحصول على الحالات التي يجب 
اختبارها بطريقة تقسيم الفغة"“ . على سبيل المثال» يمكن تغطية النوع ٥۵٣۲‏ في 
الشكل 6-5 بواسطة إنشاء سيتاريوهات اختبار تعمل على تكوين جميع الإعدادات 
الممكنة لعناصر سمات الحالة ووصع) ٣٠۵٤!‏ سام بتاءَ على مواصقات العربة. 

تكون مواصفات من آلة تحديد الحالة ۴5M‏ أو واطتهاهاS‏ متوفرة غالبا 
كما إن هناك أدوات فاعلة جيدة لإنشاء سيناريوهات الاختبار» التى تضمن تغطية 
كاملة لسلوكيات الكائن بناء على المواصفات والمعايير المنتقاة. هناك العديد من 
الخبرات الناجحة التي رواها کل من برایند 8i۵‏ وکیو ٥i‏ ولابایتش 
OL abiche‏ وکل من *PMeisingery Imoberdorfy Hartmann‏ . 

هذا وتكون مخططات التسلسل ومخططات التشارك ومخططات النوع 
متوفرة أيضاً. بذا يمكن إنشاء سيناريوهات الاختبار من هذه المخططات لكن 
إكمال اشتقاق مجموعات الفحص يعتمد على دقة هذه المخططات. 

لا تتوفر لتقنيات النوع الداخلي فرص كثيرة للعثور على أخطاء في العملية 
صم االله لأنها تهدف إلى كشف أخطاء التكاملء في حين آن أخطاء هذه 
العملية تكون أخطاء وحدة (انصن). 


5 6 تقنیات الاختبار الجبري 

تدعم المواصفات الأساسية إنشاء سيناريوهات الاختبار والمشاورات 
أوتوماتيكياً. اقترح کل من رونك کو دونغ ع«0ه( وفرانکل Frank!‏ تقنية 
جيدة لأتمتة عملية إنشاء سيناريوهات الاختبار من المواصفات الجبرية في نظام 
1ك . لكن ١٥ط‏ وآخرون قاموا بتوسيع الاقتراح الأصلي ليشمل نظام 
"A٣٤٤‏ الذي يتعامل مع مجموعة أكبر من السيناريوهات. 


يتم إنشاء سيتاريوهات الاختبار أوتوماتيكياً عن طريق جمع قواعد جبرية 
بطريقة ملائمة. فإذا أعطي النوع ٤‏ والتسلسل ٠‏ لتنفيذ عمليةء فإن التسلسل 
المكافئ يكون عبارة عن تسلسل للتنفيذات التي تنتج منها نفس النتائج بالنسبة 
إلى ال »١‏ في حين أن التسلسل غير المكافى هو الذي ينتج نتائج مختلفة. 
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السيناريو المكافئ هو زوج من التسلسلاث المكافئة» في حين أن السيناريو غير 
المكافئ هو زوج من التسلسلات غير المكافئة. تبدأ التقنية يمجموعة من 
أوتوماتيكياً من المواصفات الجبرية. يتم تقبيم نتائج تنفيذ سيناريوهات الاختبار 
أوتوماتيكياً بعقارنة نتائج السيناريوهاث المكافئة وغير المكافئة. 


Cart) 

addltern(code, qt) 
renoveltem{code) 
updateltem{code, qt} 
getQuantity{code) 
getNum'TotIterns) 
commit) 


الشكل (5- 7): واجهة النوع ا٣١‏ 


type Cart 
ayntax 
create: 4 Cart 
addItern: Cart x String xX Integer + Cart 
removeltem: Cart x String + Carl 
updateltem: Cart x String x Integer + Cart 
getQuantity: Cart x String 4 Integer 
getNurmn'Totitems: Cart 4+ Integer 
commit: Cart + Carl 
declare 
Û: Cart 
x, yi Integer 
s5: String 
semantics 
1: getQuantity{create, s) 4+ Û 
2: getQuantityladdltem(C, s, x), s8} >4 x 
3: getQuantity{addliem(C, t, x), s8) + getQuantity(O, s} 
4% updateltem{create, s, x} -+ create 
5: updateltem(addltem(Û, s, y}, s, x} 4 addltern(@, s, x) 
6: updateltem(addlten(Û, t, ¥), 8, x) 4 additem[(updatelten(C, s5, x), t, ¥} 
7: removeltem{create, s) ¬+ create 
8: removeltem(addlItem(C, &, y}, 5) =+ removeltem(C, s) 
3: removeltem({addktem(C, t, y}, 3} ¬+ addltem{removeltemn{C, s8), t, y} 
10: getNumTotltems(create} 4 Û 
11: getNumTotltems(addItem(O, s, x}} 4+ 2+ getNumTotItens{remaveltem{C, s}} 
13: commit(C} + create 


الشكل (8-5): مواصفات النوع ا٣١‏ 
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على سبيل المثال» لتفترض النوع مه٥‏ الذي يطبق الواجهة المبيّنة في 
الشكل 5 - 7 والمواصفات الجبرية المبيّنة في الشكل 5 - 8. تحدد المواصفات 
الجبرية جميع التسلسلات الممكئة لتنفيذات العملية. بشكل عام» فإن مجموعة 
جميع التسلسلات التي يمكن إنشاؤها بتطبيق القواعد الجبرية فقط هي مجموعة 
لانهائية. يمكنتا تقليل مجموعة التسلسلات بأخذ التعبيرات الأساسية فقط - آي 
تلك التعبيرات التي يمكن اشتقاقها مباشرة من البديهيات عن طريق استبدال 
المتغيرات بالصيغ الطبيعية . لسوء الحظء يكون عدد التعبيرات الأساسية كبيراً 
جداًء إذ لا يتاح استخدامها عملياً. 
يحد نظام ۸81001 من مجموعة سيناريوهات الاختبار عن طريق تعريف 
تسلسل تنفيذات العملية مع عمليات” غير تحقيقية مختلفة ذات حدوث 
متكرر» وبمراعاة جميع تراكيب قيم المعامل التي تحدث في المرواصفات 
المشروطة" . على سبيل المثال» سيناريوهات الاختبار للتوع ا۴ه٣‏ هو : 
Soart = Cart (0, addItem ("001",1), addIterm ("002",3), addItem ("003",4), re-‏ 
moveltem ("033"(‏ 


يتشئ النظام ۸51001 تسلسلات مكافثة عن طريق تطبيق بديهيات 
التحويل أوتوماتيكياً على التمثيل الشجري 40١١‏ للتسلسل المبدئي (بديهيات 
التحويل هى جزء من المواصفة الأصلية). على سبيل المثالء بإمکان ۸5۲001۲ 
إنشاء التسلسل المكافى التالي للنوع الفرعي ۴ه ويحصله من التوع اجه 
بواسطة تطبيق البديهيات 7 و8 و9 في الشكل 8-5 
Sequivalent = Cart (), addItem ("001",1), addItem ("002",3)‏ 
يُنشئ النظام 481001 تسلسلات غير مكافثة عن طريق تعديل شيم 
المعامل للتسلسلات المكافئة لانتهاك الشروط الضرورية. على سبيل المثالء 
بإمکان 48100١‏ إنشاء التسلسل غير المكافى التالي للنوع الفرعي ا٣aءء‏ 


Snon-equivalent =5 Cart (0, addItem ("001",1), addItem ("002",3), addItem 
("003",4) removeItem ("002") 


ویتم ذلك بتعدیل معامل التنفيذات الأخيرة فی Sequivalent‏ £ وبتاءَ على ذلك 
٠‏ (2) العملية التحقيقية للنوع © هي تلك التي تنتج قيمة ولا تعدل من حالة امرحلة التي طبقت عليها. 
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يتم انتهاك الشرط الذي يتطلب أن يكون مُعايل العملية ٤۷61ء‏ مساوياً 
لمُعامل التنفيذات الأخيرة للعملية ١ء‏ ا1لفة . 


يعمل "4٣٣1#‏ على تنقية التقنية التي يعرضها نظام ۸8۲00١‏ بواسطة 
توسيع مفهوم العسلسلات المكافعة. فنظام ۸8۲00۲ يراعي أن یکون 
تسلسلان متکافتین عندما يمکن تحويل أحدهما إلى تسلسل آخر بتطبيثق قواعد 
إعادة كتابة المواصفة. هذا التعريف لا يراعي التسلسلات التي تؤدي إلى حالات 
مكافئة» حتى لو كانت غير محرّلة إلى تسلسلات أخرى بمراعاة قواعد إعادة 
الكتابة. يلتقط 1۸۳٣1۴‏ هذه الحالات بمراعاة أن يكون تسلسلان متكافثين إذا 
كان كلاهما قابلاً للتحويل إلى التكافؤ نفسه . 


یقارن ۸8۳00١‏ نتائج تنفيذ السيناريوهات المكافئة وغير المكافثة مع 
العملية صوء (وقد يحون ذلك متكررا). يمكن تطبيق العملية د۹ء بالرجوع إلى 
مواصفاتها الجبرية أو بمقارنة قيم خصائص الحالة المطبقة. أما العملية هبه 
المحكومة بالمواصفات فهي أسهل»ء لكنها قد تحذف بعض تفاصيل التطبيق؛ 
بينما تراعي العملية موه المحكومة بالتطبيق جميع التفاصيل› لكنها قد تفشل 
عند مقارنة الحالات المتكافثة منطقياًء التي تختلف عن تفاصيل التطبيق غير 
المرتبطة بالعملية. قد تكون العملية دوه معقدة تماماً بالنسبة إلى الکو 
الكبيرة. أما "٣٣1#‏ فيقدم سياقات مرتبطة وقابلة للمراقبة لتضيق مجال 
السلوكيات التي يجب التحقق منها لإثبات تكافؤ الكوائن" . حدسياًء يقارن 
"A٣٤۶٤‏ حالات الكائن عن طريق مطابقة خصائصه وعن طريق التحقق من 
نتائج تنفيذات التسلسلات التي تعتمد على الخصائص المختلفة (أي سياق 
الخصائص المرتبط القابل للمراقبة). تحدد السياقات المرتبطة القابلة للمراقبة عن 
طريق استخدام مخطط بياني للبيانات ذات الصلة» الذي يمكن بناؤه من الشيقرة 
المصدرية للنوع" . يمكن أن تعمل هذه التقنية على التحقق من التكافؤ بين 
حالات الكائن أوتوماتيكيا وذلك بتوفير معلومات إضافية من قبل مصمميى 
الاختبار كمجموعة العمليات التحققية. ٠‏ 


يمكن آن تكشف التقنيات الجبرية الأخطاء في العربة المبيّنة في الشكل 1-5 
ذا کاتت استراتيجية الاختبار المبدئية تتضمن حالتی تنقيذ للعملية addItem‏ على 
الأقل. توفر السيناريوهات المكافثة إجابات تلقائية» التي يمكنها أن تحدد الخطاً 
إذا تضمّنت حزمة الاختبار سيناريوهات اختبار كاشفة. تقدم التقنيات القائمة على 
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المواصفات الجبرية آفكاراً مهمة لإنشاء الإجابات الموئثوقة التى يمكن 
استخدامها في السياقات المختلفة. ٠‏ 

إن الاختبار المعتمد على المواصفات هو التقنية الأساسية لتصميم 
سيناريوهات الاختبار. يمكن اشتقاق سيناريوهات الاختبار من النوع «الصندوق 
الأسود؛ مبكراً في دورة حياة البرمجية من دون معرفة تفاصيل الشيفرة البرمجية؛ 
وتكون فاعلة في الكشف عن العديد من الأخطاء. لكن قد يغفل الاختبار 
المعتمد على المواصفات بعض أنواع الأخطاءء وتحديداً تلك التي تعتمد على 
التصميم التفصيلي وخيارات التنفيذ التي لا تنعكس فى المواصفات. إضافة إلى 
ذلك» إن قياس مدى تغطية حزم الاختبار القائمة على المواصفات قد لا يكون 
سهلاً دائماء إذ يقترن هذا النوع من الاختبار مع الاختبار المعتمد على الشيفرة 
البرمجية لالتقاط أخطاء التصميم والتنفيذ ولتوفير مقاييس تغطية بسيطة. 


5 7 الاختبار المحدد بالشيفرة البر ية 

تغرف معاییر الاختبار المحدد بالشيفرة البرمجية من حيث التوصيفات 
البرمجية التي لم تختبر في أثناء تنفيذ سيناريو الاختبار. تتطلب المعايير 
الكلاسيكية تغطية البيانات والفروع والشروط والقرارات والمسارات والعلاقات 
الإجرائية الواجهة لكنها تهمل السلوك المعتمد على الحالة» وهي بذلك لا 
تنطبق جيداً على اختبار النوع الداخلي والبيني. 

اقترحت معايير هيكلية جديدة للتعامل مع السلوك المعتمد على الحالة. تم 
تعريف مجموعة من المعايير الهيكلية القائمة على الحالة بواسطة تطبيق معايير 
اختبار تدفق البيانات الكلاسيكية*' * * على بيانات الحالةء وذلك بتاءَ على 
تعريفات الحوسبة واستخدامات خصائص الكائن” “< . تراعي معايير اختبار 
تدفق البيانات التعريفات» واستخدامات خصائص الحالةء أي العبارات التي 
ثؤثر فى القيمة المرتبطة بالخصائص أو التي تعتمد على القيمة المرتبطة 
بالخصائص على التوالي. تقرن معابير تدفق البيانات التعريفات وتستخدم ذلك 
للإشارة إلى خصائص نفس الكائن (أزواج ءوu-اءل)‏ وتتطلب تغطية مسارات 
البرنامج التي تجتاز الأزواج عودں-٤ءل»‏ بمعنى آن المسارات التي تختبر التعريف 
أو ومن ثم تستخدم نفس الخاصية من دون أن تجتاز تعريفات إضافية 
للخاصية بين التعريف المراعى والاستخدام. بهذه الطريقةء فهي تختبر عمليات 
التنفيذ التي تغير حالة الكوائن قبل غيرها (تعريفات خصائص الكائن) ومن ثم 
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تستخدم الحالة الجديدةء ما يژدي إلى فشل محتمل يعتمد على حالات 
الخطاً. هناك معايير كثيرة لاختبار تدفق البيانات تختلف باختلاف مجموعات 
آزواج def-use‏ التي تتطلب تغطية جميع زواج eوu-‏ عل العملية في البرنامج. 


5 - 8 الاختبار الهيكلي للنوع الداخلي 

تختبر تقنيات النوع الداخلي السلوكيات القائمة على الحالة للانواع 
المفردة. فهى تختبر تعريفات واستخدامات المتغيرات التى لا تتجاوز وضوحيتها 
حدود التوع: أي أنها لا تتفاعل مع أنواع أخرى. يمكننا أن نحدد تعريفات 
واستخدامات مواصفات الكائن بالرجوع ! إلى تمثيل مخطط تدفق تحکم پاش 
۴6 للنوع. يمكن بناء مخطط تدفق تحكم النوع بخوارزمية قذمها کل من 
هارولد (ف01٤۴1)‏ ورذرميل (1ء”۲ءطاهR)‏ . مخطط تدفق تحكم النوع هو 
رسم بياني يمٿل نوع مين» حيث : 


® تہ كل عملية بواسطة مخطط تدفق التحكم» الذي يمكن حوسبته 
عن طرپق الخوارزمية التي قدمها کل من باندي (Pande)‏ ولاندي 
)Lan(‏ ورایدر (erلy‏ )32 . 


e‏ يمتّل کل استدعاء لأعملية بواسطة نقطة استدعاء وإرجاع› التي ترد 
بالعملية المستدعاة ونقاط الخروج على التوالي. 


© جميع العمليات العامة تمثل بواسطة متحكم النوع الذي يُنمذج إمكانية 
استدعاء العمليات العامة بأي ترتيب كان. يتكون متحكم النوع من نقاط 
إدخال وحلقة واستدعاء وارجاع وخروج. نقاط الاستدعاء والإرجاع 
ترتبط مباشرة بجميع العمليات العامة؛ أما نقطة الحلقة فترتبط بنقاط 
الاستدعاء والإرجاع لتمتل ! إمكانية تکرار استدعاء ات عشوائية عدد معين 
من المرات؛ تمٿل نقاط اللإدخال والخروج بداية التنفيذ وانتهاء‌ها. 


يبيّن الشكل 5 - 9 مخطط تدفق التحكم للنوع مه٤‏ الذي أوضحنا شيفرته 
البرمجية في الشكل 5 - 1. تتكون حالة هذا النوع من متغيرين : ”عا 
وnumrottems.‏ يمکن استخدام مخطط تدفق التحكم لحساب زواج def-use‏ 
بواسطة التأشير أولاً على مخطط تدفق التحكم بالتعريفات والاستخدامات» ومن 
ثم اجتياز المخطط لحساب الأزواج. على سبيل المثال» بالنسبة إلى المتغير 
num TotItems‏ التابع للنوع ۸ یمکننا تحدید التعریفات في العمليات Ca‏ 
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commit ()‏ )( yوaddItem‏ )( وremovetem‏ ()» وتحدید الاستخدامات في 
اlnad getNunTotIltems‏ )( وadditem‏ )) وremnovetemn‏ ()» ويمكننا حسابپ 
ها مجموعه 12 زوجاً غا من أزواج def-use‏ . 


Es‏ ص وق ڪڪ ڪڪ جڪ أ 


ai ESD] 


HastTatle pu] 


E 


Laem] 


HlasiTable keys) 


Has!T able hasM‏ أ 


oreElemeni) | 


getQuantity) 


mp0! = llemids,hasMorsE lemont() 
ا‎ 
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الشكل (9-5): مخطط تدفق تحكم النوع ٣ه‏ الذي أعطيت شيفرته البرمجية في 
الشكل 1-5 


يمكن أن تكشف اختبارات تدفق البيانات عن العيوب الموجودة في 
النوع ٣ه‏ لانه أزواج عود-امل التي يجب شمولها تتضمن تعريف المتغير 
uot tens‏ في العملية صءالله () واستخدام في العملية صعااللa‏ 0. 
وكما يحدث دائماًء إن اختبار العبارة الخاطئة في حالة الخطا لا تضمن أن 
الخطاً سيكشف»› حيث إن حدوث الخطاً قد لا ينتج منه خطا منظور في جميع 
حالات التنفيذ. 
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لتتابع في مثال العربة» المتغير ها1 معرّف في العمليات a1‏ 0 و commit‏ 0 
ويستخدم في lalnallت O0 updateltemy ¢) removeltemy ( addItem‏ 
وiyاi getQ uan‏ () وانصسصەت () (مرتین في اللأسطر 4 و47). ينتج من هله 
التعريفات والاستخدامات 12 زوجا عوں-اعل والتي يجب شمولها لتحقيق 
المعايير. التحليل السابق للمتغير كا غير مكتمل ذلك آنها لا تراعى متغيرات 
العنصر التابع له: المتغير ”عاذ هو كائن ذو بنية حالة معقدة؛ إذا قمنا بتحليله 
كمتغير بدائى فإننا نفتقد تأثير استدعاء العمليات الخاصة به. على سبيل المثال» 
إن استدعاء العملية الموجودة في السطر 10 لا تعتبر كتعريف للمتغير 8٠ا‏ في 
التحليل أعلاه حتى لو تغيرت حالة المتغير 6۳8ا1. 

إن تحليل تدفق البيانات للنوع عاطو٤طءه٨‏ يحسّن من الوضع جزئياًء حیث 
إن زواج ]مل المحسوبة للتوع عاطة)وة٨‏ تنتج متطلبات الاختبار التي تعود 
إلى عمليات النوع «(Ptashtable‏ لکنها لا تراعي كيفية استخدام هذه العمليات 
في النوع Cart‏ . 

على سبيل المثال» يمكن تحقيق متطلبات اختبار النوع عاط4ا 5a1‏ 
التي تتطلب تنفيذ العملية put‏ متبوعاً بالعملية اع بواسطة زوج واحد من 
عبارات النوع 0. على کل» يتضمن النوع أزواجاً مختلفة عديدة 
( <51 ,10> ,<10,41> ,<10,29>) تستحق أن تختبرء لكن لا يتم اختبارها 
بما آنها تشير إلى الأزواج نفسها في الوم Hashtable‏ . اٹ استہدال استدعاءات 
عمليات الأنواع الخارجية في مخطط تدفق التحكم مع 1٥۴٥‏ سيتتج منه آزواج 
ماعل إجرائية داخلية» لكنها لم تزل تفتقد التعريفات والاستخدامات التاجمة 
عن تأثیر نوع على آخر. 

يمكن أن يتم تحسين تحليل سال للنوع الداخلي عن طريق احتساب 
التعريفات والاستخدامات التي تتضمن السياق الذي يعرف المتغيرات وتستخدم 
فيه. بهذه الطريقةء على سبيل المثال» سيكون بإمكاننا تحديد جميع آزواج def-‏ 
مون التاجمة عن تأثير التوع ا٣٣‏ على التوع امه . 

التقنيات المتأئرة بالسياق موضحة في القسم التالي. 

(3) لا تعود متطلبات الاختبار على العمليات» لكنها تعود على تعابير البرنامج. لتبسيط هذا المال» نحدد 
متطلبات اختبار النوع عاطهااة11 من حيث العمليات التي تتضمن تعريفات واستخدامات» بدلاً من ثعابير 
برنامج مفرد. 
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5 9 الاختبار الهيكلي للنوع البيني 

تعنون التقنيات المتأثرة بالسياق اختبار النوع البيني من خلال زيادة 
التعريفات والاستخدامات بسلاسل من الاستدعاءات التي تقود إلى تعديلات 
ووصولية للمتغير. يمكن تعريف متغير الحالة ٠‏ للزوج ماعل كزوج من 
تسلسلات الاستدعاء (ن,ل) حيث : 

d = CD,CD,...CDmD, U = CU,CU,...CU,U, CD; 

ورلا فهي استدعاءات للعملية. © هي عبارة البرنامج التي تعرف ١‏ أما 
ا فهي عبارة عن برتامج يستخدم المتغير 0. هذا مثال على سلسلة استدعاء 
طولها 3 ناتجة من تنفيذ النوع عاطهاطءها الموضح قي الشكل 5 - 10ء تتكون 
من 41-25 و10-ه و6-ماطاهاطهه۴ التي تشير للتعريف المتغير المشتق من 
تنفيذ السطر السادس في النوع عاطعاطوها الذي ينتج من تنفيل السطر 10 من 
النوع اموت الناجم بدوره عن تنفيذ السطر 25 من النوع أ٣ه©,‏ 


public svachrotized ¥ puLl(K key, ¥ value) { 
if (value uull) ¢ 
throw tew NullPoinltel Exceptiob(): 


١ 
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الشكل (5 - 10): مقتطفات من تتفيذ النو ع ۴1411416 


إن الزوج ماعل (سرل) لمتغیر ٥‏ پتم اختباره عن طربتق عملية تنفيذ 
تتضمن استدعاء التسلسل ل متبوعاً باي تسلسل لاستدعاءات العملية التي لا 
تعذل وتتتهي بتسلسل الاستدعاء ناء 

يمكن تنفيذ هذا التحليل بمستويات تعمق مختلفة. يعرف ساوتر وولو ك9 
أربعة مستويات تدعى 0الت وا-اله و2-اله و3-سلء. يتطابق المستوى 0-uله‏ 
مع تحليل ع«د عل غير مرتبط بالسياق» كما هو مين في القسم 8-5. في هذه 
وتسشخدم المتغير. آما المستوی 1الت فیشير إلى تسلسلات استدعاء ذات طول 2+ 
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آي آنها التسلسلات التي تتضمن المستدعي وعبارة البرنامج فقط التي تعدل 
المتغير وتستخدمه. أما المستويان 2-سله و3-سلء فيوسعان التحليل ليشمل 
الاستدعاءات ذات الأطوال 3 و4 على التوالي. 

بالإشارة إلى التنوع عاطة٤طوه‏ المستخدم من قبل النوع اتة٣»‏ وكما هو 
مبيّن في الشكل 1-5 فإن المستوى 1-دلء سيقترن بتعريفات النوع 1م۸81 
التي تشتق تشتق من استدعاء صعاآادام عند العبارة رقم 10 من من النوع ga Cart‏ 
استخدامات النوع Hashtable‏ التي تشتق تشتق من استدعاءات ”)االله عند العبارات 
29ء 34ء 41 47 51 (تعريفات واستخدامات متغيرات حالة مفردة التي یتم 


الحصول عليها من تحليل الشيفرة المصدرية للترع عاطةاطهة) . 

قيس معايير اختبار ثدفق البيانات اكتمال مجموعات الاختبار لكنها لا توفر 
عملية لإنشاء سیناریو هات الاخبار. یجع کل من باي Buy‏ وأورسو Dpezzêy Orso‏ 
berzê‏ تحالیل تدفق | البيانات ا تنفيذڏ رمزې واختصار آوتوماتیكي | لإنشاء 
احتقساب آزواج E defuse‏ نوقش فی القسم 7-5 ومن ثم يتم إنشاء 
سيناريوهات الاختبار التي تغطي الأزواج المعرفة. يتم إنشاء سيناريوهات 
الاختبار بخطوتين : 

آ) التنفيذ الرمزي الذي يحدد () المسارات التي تغطي الأزواج عو- ]ءل و(2) 
شروط المسار المرتبطة (أي قيود متغيرات الحالة التي تسبب تنفيذ المسارات). 

ب) الاختصار الأوثوماثيكى الذي ینتج تساسلات استدعاء كامل بواسطة 
تکوین شروط المسار للإنشاء سیناریو هات اختبار عملية. 


5 10 الاختبار في ظل وجود التوارث 

يتيح التوارث لمهندسي البرمجيات تنفيذ آنواع جديدة كأنواع فرعية تابعة 
للأنواع المتوفرة أصلا. الأنواع الفرعية تعيد استخدام بعض وظائف الأنواع 
السابقةء وتعدل وظائف أخرى»ء وتضيف وظائف أخرىء على الرغم من أنه 
يمكن اختبار الأنواع الفرعية»› يمكن كما لو كانت أنواعاً جديدة من حيث 
المبدأء إلا أن اختبارات الأنواع القديمة قد تقلل من عدد سيناريوهات الاختبار 
اللازمة لفحص النوع الفرعي فحصاً تاماً. 

على سبيل المثالء النوع ٣٣ءءسںءم5‏ المحدد بالنوع المبيّن في الشكل 6-5 
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يوشم النرع المبيّن في الشكل 5- 10. النرع SecureCart‏ يعیدك 


استخدام جميم عملیات النوع Cart‏ ما عدا constructor‏ الذي أعيد تعريفة 
ليتطلب هوية المستخدم ومعلومات اعتماده. في هذه الحالةء لا تتأثر العمليات 
الآتية بالوظائف المضافةء ولا يتطلب الأمر إعادة اختبارها: ص )الله 
removeItem ş‏ و getQuantity‏ yوgetNumTotItems‏ واmitصەc.‏ وبذا یمکننا اختبار 
النوع Secure‏ بواسطة اختبار ٣0اعu٣tومهت‏ الجديد فقط. 


بشكل عام» يلزمنا إعادة اختبار جميع العمليات التي تتأثر بالعمليات الجديدة 
أو المعدلة مباشرة أو بشكل غير مباشر. قام کل من Harrod‏ وماكغريغور 
0rْعMoeCre‏ وفيتسباتريك DFitzpatrick‏ بجمع سيناريوهات الاختبار الهيكلية 
والوظيفية حسب العمليات التي يتم اختبارها ونوع الاختبار (وحدة أو تكامل)» 
وقاموا بتحديد سيناريوهات الاختبار التي يجب إضافتها إلى حزمة الاختبار وإلى 
السيناريوهات التي يجب أن يعاد تنفيذها حسب العمليات المضافة والمعذّلة في 
التوع الفرعي. 

تتطلب العمليات الجديدة المضافة في النوع الفرعي سيناريوهات اختبار 
وحدة جديدة وتكاملاً (إذا كانت تتفاعل مع توصيفات أخرى). تتطلب العمليات 
التلخيصية سيناريوهات اختبار وظيفية فقط بينما تتطلب العمليات الأساسية 
سيناريوهات احتبار وظيفية وهيكلية. 


العمليات التي لم تتغير (أي العمليات المتوارثة من النوع الأم من دون 
تغییر) لا تتطلب سيناريوهات اختبار إضافية. يجب أن يعاد تنفيذ سيناريوهات 
اختبار التكامل إذا كان النوع الفرعي يعدل التكاملات بعملية معادة الاستخدام. 

آما العمليات المعاد تعريفهاء آي تلك التي غيرها النوع الفرعي» فتتطلب 
إضافة سيناريوهات اختبار وظيفية وهيكلية جديدة إلى السيناريوهات المتوفرة 
التي يتوجب إعادة تنفيذها. إذا كانت العملية تتفاعل مع توصيفات أخرى» علينا 
آن نشتق سيناريوهات اختبار التكامل وسيناريوهات اختبار الوحدة. 


5 - 11 اختبار الانحدار 

في أثتاء عملية التطوير»› بُنتج مهندسو البرمجيات إصدارات عديدة من 
الأنواع التي تكوّن النظم ارما كما في حالة التوارث» يتم اختبار جميع 
اللاصدارات کما کانت اعا جديدة هره دول اعاة سینارد هات الاختبار 
ٌ أو مں مر نر 
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المشتقة للإصدارات السابقة» وهذا يسبب هدراً في الوقت والموارد. تستخدم 
تقنيات اختبار الانحدار معلومات عن التغيرات التي تتم في الإإصدارات 
الجديدةء وذلك لتحديد سيناريوهات الاختبار التى يجب أن يعاد تنفيذها 
لضمان أن الاصدارات الجديدة لا تتضمن عيوباً. تركز تقنيات اختبار الانحدار 
على الوظائف التى يجب أن لا تتأثر بالتغيرات والوظائف المضافة أو المعدلة 
في الاصدارات الجديدة التي قد تتطلب سيناريوهات اختبار جديدة يمكن 
إضافتها إلى حزمة الانحدار» ويمكن إنتاجها حسب التقنيات الموصوفة مسبقا 
في هذا الفصل. 

إن منهجيات اختبار الانحدار البسيطة ستتطلب إعادة تنفيذ جميع 
سيناريوهات الاختبار المشتقة لجميع الإصدارات السابقة» وبذا تقلّل من جهد 
تصميم الاختبار»ء لكن لا تقلل من زمن تنفيذ الاختبار. يمكن أن تؤدي هذه 
المنهجيات إلى تنفيذ العديد من سيتاريوهات الاختبار حتى بالنسبة إلى التغيرات 
والنطاق المحدودة. اقترح العديد من الباحثين تقنيات لاختيار مجموعات جزئية 
من سيناريوهات اختبار الانحدار للبرمجيات كائنية التو ج1“ 4 ٠25‏ 04 , 
بعض هذه التقنيات آمنةء بينما بعضها الآخر غير آمن. تضمن تقنيات اختبار 
الانحدار الآمنة أن المجموعة الجزئية المنتقاة من سيناريوهات الاختبار لن تغفل 
أياً من العيوب التي يمكن أن تكشفها مجموعة سيناريوهات الاختبار الأصلية» 
بينما قد لا تكشفها التقنيات غير الآمنة. 


المنهجيات الشائعة المستخدمة في النظم كائنية التوجه تستند إلى تعريف 
الجدار التاري اله سء الذي يمتل مجموعة من الأنواع التي يمكن أن تتأثر 
بالتغيرات التي تطرأً على الإصدارات الجديدة** #* 6 . يتم حوسبة جدار 
الحماية بناء على التخيرات التي يمكن أن تحدد أوتوماتيكياً بواسطة مقارنة 
الشيفرة المصدرية لإصدارين مختلفين» بينما يمكن حوسبة مجموعة الأنواع التي 
يمكن أن تتأثر بالتغيرات بمراعاة التوارث والانحدار والعلاقات المرتبطة (بعض 
المنهجيات تأخذ في الاعتبار الروابط متعددة الأشكال والروابط الديناميكية). 
تقارب معظم العمليات جدار الحماية عن طريق مراعاة بعض العلاقات فحسب. 
التحديد الجيد لجدار الحماية هو ما يضمن الأمن فقط› لكن التحديد الجيد 
غالباً ما يكون مكلفاً. إن مجموعة سيناريوهات اختبار الانحدار التى يجب إعادة 
تنفيذها هي مجموعة السيناريوهات التي تنْفَذ الأنواع التي تنتمي إلى جدار 
الحماية لجميع الأنواع المعدلة. إن جدار الحماية المحوسب وتحديد 
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سيناريوهات الاختبار التي يج يجب إعادة تنفيذها بسيطة. على كل » لا تكون التقنية 
المستخدمة فاعلة دائماً: فبعض التغيرات يمكن أن تختار تخار جم سیتاریوهات 
الاختبار من الحزمة الأصلية» وبذا يقل الزمن اللازم للتنقيذ. وبناء على ذلك» 
يجب أن تستخدم هذه التقنية للتغيرات الصغيرة والمتزايدة. " 


ثمة منهجيات أخرى تختار حزم الانحدار للبرمجيات كائنية التوجه من 

معلومات تدفق التحكم. . يقترح کل Harrold, Rothermel jn‏ وديدھيا 
ھنطلە( تقنیات ترتکز علی مخطط تدفق تحکم النوع ٥٥۴٩۵‏ . آما الفروقات 
بين الأنواع» فهي محددة عن طريق مقارنة مخططات تدفق تحكم النوع الخاص 
بها. تكون مخططات تدفق تحكم النوع مرفقة بحواشي عن معلومات التغطية - 
أي أنها تكون مرفقة بمجموعة من سيناريوهات الاختبار التي تغطي الحواف 
موفرة بذلك المعلومات اللازمة لتختار أوتوماتيكياً السيناريوهات الثى يجب أن 
يعاد تنفيذها. هذه التقنية آمنة» كما أنها تعمل في حال اختبار النوع الداخليء 
لكنه لا يجدول اختبار النوع الداخلي فورياًء كما آن هناك مزايا كالروابط 
الديناميكية قد تعقد عملية التحليل بشدة. 


تم التحقق من الفكرة الأساسية التي يقدمها المرجع“ من قبل لاه ۸2۲۲ 
وآخرین» حیٹ اموا بعتونة برامج جافا | التي تمثلها مخططات انوع الداخلي 
بما في ذلك معالجة الاستشناءات والتطبيقات غير المكتملةء وبذا فهي تدعم 
تحليل العديد من المزايا التي لا تتوفر في مخطط تدفق تحكم الثوع. 


5 12 الاستنتاجات 


التصميم كائني التوجه يُقَلّل من تكرار حدوث بعض أنواع الأخطاء 
التقليدية› لکنه يكشف مشكلات جديدة لم يتم كشفها بشكل كاف بواسطة 
الاختبارات وتقنيات التحليل التقليدية. تساعد الحلول العديدة على فهم منظور 
المشكلات وتحدد بعض المنهجيات المفيدة. إلى غاية الآنء ركزت الأبحاث 
على بعض المشكلات» على سبيل المثال» تلك التي تشتق من السلوك القائم 
على الحالة والتضمين والتوارث وتعدد الأشكال وعدم ک كشف العديد من 
المشكلات الكبرى الأخرى» مثل المشكلات التي تشتق من استخدام 
العموميات والاستفناءات. 
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لكن ما هو أكثر أهمية» الحلول التي لا توفر إطار عمل كامل وناضج 
لاختبار النظم كائنية التوجه. 


يعمل الباحثون بنشاط على التحقق من المنهجيات الجديدة للتغلب على 
مجموعة المزايا كائنية التوجه بأكملهاء إضافة إلى الموازنة جيداً بين اختبار 
النظام الوحدوي والتكاملي. يعمل المتمرسون في هذا المجال على جمع 
البيانات عن مدى حدوث العيوب وتوزيعها في البرمجيات كائنية التوجه؛ وهم 
يتفهمون التحديات الجديدة لاختبار النظم كائنية التوجه أكثر من ذي قبل» وهم 
يدينون بفضل للحلول التي تقدمها مجموعات البحث. 


إن هذا الإدراك المتنامي للمشكلات والحلول ستؤدي قريباً إلى ظهور جيل 
جدید من آدوات C۸8۴‏ التي ستتعامل مع اختبار وتحليل النظم كائنية التوجه 


بكفاءة. 
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لخة النمذحة الموحدة والأساليب النظامية: 
دراسة حالة استخدام 


(Carlo Montangero) gرıڍغنiتige‎ gلراک‎ 


6 1 مقدمة عامة 


معظم المنهجيات المعروفة لتطوير البرمجيات تطورية في الوقت الراهنء 
بما في ذلك الأساليب السريعة مازع والعمليات الموحدة (0۴)؛ آي إنها 
عبارة عن منهجيات دورية» كما هو موضح في الشكل 1-6. بعد التحليل 
التمهيدي الذي يستهدف الجدوى الإجمالية وتقييم المخاطرء تدخل عملية 
التطوير دورة مقسمة إلى فترات برمجية دورية و«هناهءه): يتم في كل منها تحليل 
وتصميم وبناء جزء من النظام (كخاصية معيّنة أو سيناريو استخدام» إلى غير 
ذلك)ء ما يتيح للمُستخدم إمكانية استخدام أجزاء متتابعة من النظام يزيد عدد 
الوظائف والمزايا والجودة في كل منها على سابقه. تكمن الميزة الأساسية لهذه 
المنهجية في المرونة العظيمة في التجاوب مع التغيير الطارئ على المتطلبات 
الذي تفرضه الطبيعة المتطورة لبيئات الأعمال الحالية. 


تختلف المرحلتان اللتان تتكون منهما الدورة في أن التنفيذ يركز على 
الشيفرة البرمجية» ويكون نطاق العمل صغير (أي المتطلبات المطلوب تنفيذها 
في الدورة الواحدة)ء نظراً إلى أن الشيفرة البرمجية تكتب حسب بعض 
المواصفات» بينما يركز التحليل والتصميم على عدد كبير ومتنوع من النماذج 
ويكون النطاق في هذه الحالة أكبرء إذ يتم إنتاج النمافج بناء على المتطلبات 
ككل. النماذج التي يتم بناؤها في مرحلتي التحليل والتصميم تكون عبارة عن 
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مستوعبات للمعرفة الثي يتم تحصيلها عن النظام والغرض المرجو من بنائه. 
تتيح هذه النماڈج للمطؤرين الوصول إلى فهم أعمق عن مزايا النظام قبل وقت 
كافي هن بنائه. كما أنها ساس عملية الشصميم المشثركة الي تعتبر جوهر تطوير 
البرمجيات الحديئة. 


الشكل (6 - 1): دورة حياة الغطور 


المرحلتان مثشابهتان أيضاً حيث إنهما ترتكزان على حلقاث بناء ومراجعة 
و[إصلاح تكراربة آضيق. لذاء فهما تختلفان قي المعطيات التي تعملان عليها 
لكنهما متشابهتان في العملية (عمل وإصلاح)؛ هذا وتعتمد كفاءة عملية التطوير 
على درجة الدعم الأوتوماتيكي يدرجة كبيرة. في هذه الأيام»؛ يتم دعم 
المرحاتين بدرجات مختلفة في هذا الصدد. تكون عملية التنفيذ تامة طالما أنها 
مرت بفترة بحث وبرمجة طويلة» ويتم دعمها من قبل أدوات وفيرة كأدوات 
التجميع وآدواث التدقيق وآدواث التنقيح والبناء وآدوات الربط للاختبار. كما إن 
هناك عدداً من الأدواث المستخدمة لدعم التحليل والتصميم تم تطويرها من قبل 
لجنة البحث عن الأساليب الرسمية» كما يتم تطوير المزيد من الأدوات. لكن 
تبني هذه الأدوات من قبل الممارسين ليس متقبلاً بصورة واسعة. پرتبط جڙء من 
المشكلة بالتنوع العظيم للمنهجيات» حيث لكل منها الشكليات الخاصة بها 
وأهداف پرجى تحقيقها. 

إضافة إلى ذلك» فد بكون مستوى التشكيل نفسه مشكلة» ذلك أنه قد 
بستلزم منحنى تعليم شديد الانحدار حيث يتطلب درجة تعليم لا تكون متوفرة 
في الأغلب في بيئاث البرمجة المتوسطة. 

اتخذ مشروع 0۴648 خطوات لتعزيز الاستخدام المباشر لأدوات 
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التحليل من قبل مصممين ذوي مسٹوى مثوسط. تكمن الفكرة الموضحة في 
الشكل 2-6 في إتاحة المجال أمام المطؤرين أن يسشخدموا البيئة التطويرية 
الخاصة يهم في أثناء إجراء عمليات التحليل في بيئة الشحقق الخاصة بها. فحثى 
يتم تحليل نماذج التطوير في بيئة التحقق» يجب البده باستخدام أداة استخلاص 
(إەامة×E)‏ تعمل على استخلاص أجزاء من النموذح الذي سيكون مرتبطا 
بالتحليل وبضعها في بيئة النحقق. بعد آن تكتمل عملية التحليل» تكون نتائج 
الشحليل مثوفرة للمطرر باستخدام عاكس (٣ماععه۸).‏ غالياً ما يٿم عرض 
النتائج كتنسيق مرتب للنموذج الأصلي. حتى تكون هذه المنهجية عملية من 
وجهة نظر المطرّر» يجب أن تكون أداة الاستخلاص وآدواث التحليل والعاكس 
مۇتمنة ومخفية عن المطور. وهكذاء لن يحتاج المطور إلى معرفة التفاصيل 
الأدق للعناصر؛ لکن قد پرگز على تصميم النظام. 


الشکل (6 - 2): مشروع 5٤6۸8‏ 


في مشروع 08648 تستثمر بيئة التطوبر لغة البرمجة الموحدة 901 
UM‏ إذ أصبح لها مؤخراً تأثير في العديد من التطبيقات المستخدمة في 
الحياة اليومية نظراً إلى شعبيتها المتزايدة. من بين الميزات التي بحققها استخدام 
لغة النمذجة الموحدة أن هناك توكيدآ على العروض الرسومية مع القدرة على 
تعديلها باستخدام أدواث الطباعة ومنهجية العرض ودعم النقض والشناقض 
(مؤقتا). تشجع هذه الخصائص الحوار مع المعنيين في المشروع حتى لو كانوا 
ذوي معرقة تقنية فليلة. في الوقت نفسه» تكون اللغة دقيقة بما فيه الكفاية لتتيح 
للمصمم التعبير عن كافة المعلوماث الضرورية لاستخلاص النماذج الأساسية 
اللازمة لشحليل. من ميزات لغة النمذجة الموحدة الجذاية الأخرى هي الخيارات 
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الكبيرة لبيئات الأعمال التجارية والدعم الحر» إضافة إلى أن لغة النمذجة 
الموحدة تندمج بسهولة في حزمة واحدة من خيارات منهجيات النمذجة 
المؤسسة جيداً المتعارف عليها بين المشاركين. 

تستخدم بيئة التحقق في مشروع ۴648( حسابات العمليات» وهي عبارة 
عن نماذج السلوك الخاصة بالنظم» وسيركز تحليل هذه الحسابات على المظاهر 
السلوكية للنظم» وبذا تتم عملية تحليل مظاهر بنية النظام بحيث تطبع هيكليات 
الكائن بشكل جيد وتكون المخططات متسقة داخلياًء وهذه هي أنواع التحليل 
التى تنقَذ فى لغة النمذجة الموحدة فى الوقت الحاضر. أما التتيجة الرئيسة 
العملية لمشر وع ۴6458( فهي الأداة Choreokrapher‏ وهو منصة تصمیم 
تكاملية لنمذجة النظم البرمجية النوعية والكمية . يتم نشر التحليل النوعي 
للتحقق من أمن بروتوكولات الاتصالات المستخدمة في التطبيق. يضمن هذا 
التحليل عدم وجود محاولات اختراق ناجحة لخاصية المصادقة على الرسائل 
المتبادلة شريطة أن لا يكون هناك آي اختراقات ناجحة للنظام الأساسي المرهز 
المستخدم لحماسة الرسائل. في حال تم اختراق عملية المصادقة» تشير عملية 
التحليل إلى النطاقات التي أحتّرقت. التحليل الكمي الذي ينفذ هو عبارة عن 
تحليل لأداء نموذج النظام. وهذا من شآنه أن يحدد المكؤّنات غير المستغلة أو 
تلك المستغلة بإفراط الذي يدل على وجود توزيع ضعيف للموارد الحاسوبية. 
يُعنى ما تبقى من هذا الفصل بتحليل الأمن والحماية. نتمسك بوجهة نظر مطرّر 
النظم» ولم نعد تخوض في الأساس النظامي للعمليات الرياضية للمنهجية. 
بإمكان القارئ المهتم مطالعة المرجم” لقراءة المقدمة العامة والمرجع” لقراءة 
مناقشة مستفيضة. هذا وقد تم استعراض التحليل الكمي في المرجع“ ونوقش 
في المرجع"'. 

يلقي القسم التالي الضوء على بعض مظاهر لغة البرمجة الموحدة ذات 
الصلة بنقاشنا؛ بإمكان القارئ ذي المعرفة الجيدة بالموضوع تخطي هذا القسم. 
ثم سنعرض ۴٥۲154‏ وھو إطار عملي» في ۲م ۲4ع 0ط یدعم المصمم 
في نمذجة البروتوكولات التي يجب تحليلها للوقوف على خروقات المصادقة. 
نناقش كيفية استغلال إطار العمل لبناء نموذج ديناميكي للبروتوكول في سياق 
النموذج الثابت ما يوفر جميع المعلومات اللازمة للتحليل. قبل عرض 
الاستنتاجات نناقش كيفية عرض نتائج التحليل على المصمَم» وكيف يقوم 
بتفسيرها في حال وجود خلل في البروتوكول. 
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6 2 نظرة منحازة إلى لغة النمذجة الموحدة 

سنبدآ بمراجعة بعض المفاهيم العامة الأساسية للغة النمذجة الموحدة. 
التصميم هو عبارة عن مجموعة من النماذج التي تصف النظام قيد البناء من 
منظورات عدة» وكل نموذج هو وصف نظري للنظام أو جزء منه. يُنظّم 
التصميم في عروض» بحيث يجمع كل عرض النماذح التي تعرض وجهات نظر 
مترابطة منطقيا عن النظام. العروض النموذجية هي عرض «حالة الاستخدام» 
الذي يقدم سيناريوهات عن استخدام النظام» والعرض التشغيلي» المعني 
باستمرارية السيطرة ۴1٥#‏ 1ها«ه٣‏ ومشكلات الأداءء والعرض «الفيزيائي» 
المعني بالربط بين المعدات والبرمجيات» وعرض التطوير؟ المعني بتنظيم 
مكوّنات البرمجية. أما العرض ذو الصلة بأهدافنا فهو العرض «المنطقي» الذي 
يأخذ بالاعتبار مكوّنات النظام عند مستوى نظري متقدم. 

قد يكون النموذج مستقلاً زمنياً (أي ثابت) ويصف بعض عناصر النظام 
وعلاقاتها: في العرض المنطقي» قد يستخدم النموذج مفاهيم معيْنة في مجال 
التطبيق» ويعبّر عنها بصورة أنواع (وءءوه1) وارتباطات. على سبيل المثال» 
سنستفید من المفاهيم : لأر (Principa1)‏ والأساسي (Message) alu jİlg (Key)‏ 
وغيرها. أو قد يكون النموذج ديناميكياً ويصف جزءً من سلوك النظام من حيث 
التفاعل بين الكوائن في النموذج الثابت ذي العلاقة (أي إن النموذج الديناميكي 
يفترض وجود نموذج ثابت). على سبيل المثال» سنأخذ في الحسبان التفاعلات بين 
العناصر الرئيسة ذات الصلة ببروتوكول الاتصال. 

ثبنى النماذج عادة بلغة النمذجة الموحدة وذلك برسم المخططات. من 
الأهمية بمكان فهم الفرق بين النماذج والمخططات. فالمخطط هو تعبير رسومي 
لمجموعة من عناصر النموذج» يُعبّر عنها برسم آقواس (تمثل العلاقات) وروس 
(تمشل عناصر النموذج الأخرى). والنموذج هو بذاته عبارة عن رسم لكن لعناصر 
ذات دلالة؛ المخطط هو عبارة عن رسم لعناصر مرئية ترتبط بطريقة ذات دلالات. 
إذاًء في أداة الدعمء النموذج هو عبارة عن بتية عمل بينما المخطط هو بنية عرض. 
أحيانآًء قد لا تكون جميع عناصر النموذج مبينة في المخطط» كما يبدو في الشكل 
36 فقد يظهر هذا الوضع إذا تم رسم 2ووها٣‏ مع علاقته ب C1893‏ في 
المخطط 2ء ومن ثم فطع من المخططء لكن لم يُحذف من النموذج. فعلى 
الرغم من أن المخططات هي طريقة أساسية لإدخال نموذج ما في أداة من أدوات 
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لغة النمذجة الموحدة» إلا أن هناك طرقاً لإدخال العناصر عبر صناديق الحوار 
وأدوات تحرير الهيكلية» بحيث تعمل مباشرة في النموذج. 


الشكل (6- 3): النماذج والمخططات 


في هءرآه۴» نحدد برتوكول الأمن في عرض لغة النمذجة الموحدة 
المنطقي» بتوفير نموذجين: نموذج ثابت يصف بنية البروتوكول» ونموذج 
ديناميكي يصف سلوكه. يُعرض النموذج الثابت كمخطط نوع (ووعاع 
rmعi()»‏ بينما يعرض النموذج الديناميكي كمخطط تسلسل (عo‏ دعي 
صهعها). نستخدم الإصدار 1.5 من لغة النمذجة الموحدة. في النتيجة» نقدم 
العناصر التي تلزم لفهم المخططات في القسم التالي بإيجاز. يمكن مطالعة 
المرجع” للحصول على مقدمة سريعة عن لغة النمذجة الموحدة. 

يصف مخطط النوع جزءاً من العالم الحقيقي من حيث الكوائن. وبتعبير 
أكثر دقة» يميز مخطط النوع الكوائن ذات العلاقة بمجال العمل من طريق 
تصنيفها وعرض بنيتها. النوع هو عبارة عن مجموعة مسمَاة من الكوائن التي لها 
البنية نفسها والمعطاة كمجموعة من الخصائص ومجموعة من العمليات. في 
المخطط» يمثل النوع بمستطيل ذي ثلائة أقسام: يستخدم القسم الأول لاسم 
النوع» والثاني للخصائص والثالث للعمليات. في بعض الأحيان» قد لا يكون 
هناك قسم للخصائص أو العمليات» ولا يكون ذلك ضرورياًء كأن يكون فارغاً. 
فكما هو موضح في الشكل 4-6» جميع مستطيلات الاأنواع في الشكل تحتوي 
على الاسم فقط من دون قسمي الخصائص والعمليات ما عدا النوع Principal‏ 


176 


(انتبه» نحن ننظر إلى هذا المخطط في الوقت الحالي من الناحية التركيبية 
فحسب» وسنتطرق إلى المعنى في القسم التالي). يكون لكل خاصية من 
الخصائص اسم ونوع (كخاصيتي دا واناه في النوع لمصنهم٣۴‏ في الشكل 4-6)» 
إذ قد يكون الاسم بداثياً أو منطقياً (يحتمل الصواب والخطاً «هء1هه8) أو عبارة 
عن سلسلة عصصا؟» أو قد يكون اسم نوع آخر في النموذج. آما العمليات»› 
كالعملية عوت» فيكون لكل منها اسم وعناصر مطبوعة والقيمة المتوقعة من 
تنفيذ العملية. بكون للعمليات والخصائص رؤية» قد تكون خاصة بالكائن كما 
في حالتنا (يعبّر عنها بإضافة إشارة الناقص - في بدايتها) أو عامة (يعيّر عنها 
بإضافة إشارة الزائد +). 


Principal 
-n:Msg 
-out:Msg 
-theDecryptedltem:DecryptedPayload 
+erypt(p1:5ymKey,p2:Data): 
+decrypt(p1:SyrmKey,p2:String): 
+aCrypt(p1:AsymKey,p2:Data): 
+aDecrypi({p1:AsymKey,p2:String): 
+msg(p:Msg): 
+îsNewKey{ :SessionKey):boolean 
+isNewinfo{ :Info):boolean 
+isNewNonce( :Nonce)}:boolean acre 
+checkmnsg(): 
+checkdecrypt(): 
ا‎ x - 
1 1 
<< singleton >> << singleton >> << singleton >> 
Server Initiator Responder 


SS ET 
a 4 
SessionKey PrivateSymKey | PublicAsymKey 


الشكل (6 -4): خطط النوع Principals‏ 
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PrivateAsymKey 


قد تكون العلافة التي تربط الأنواع من النوع «علاقة 1-4» (ويعبّر عنها 
بسهم ذي راس مثلٹ مفرغ)؛ على سبيل المثال» يبيّن الشكل 46 آن الكائن 
ga SymKey‏ آیضاً Ky‏ آي إن SymKey‏ يخصضص Key‏ او آن Key‏ يعمم 
رءKصSy.‏ إذا كان اسم النوع مكتوباً بالخط المائل فإنه يعبر عن نوع نظري 
(بمعنی آخر› نوع ليس له آي کوائن - کالنوع × في الشكل)» لكنه موجود 
ليوفر خصائص مشتركة للأنواع التي يعممها. أما العمليات التي تكتب بخط 
مائل» فهي نظرية أيضاً ويترك تعريفها للأنواع المخصصة. 

ثمة نوع آخر من العلاقات موضح في الشكل 46. فالخط ذو الرأس 
المصمت يعبر عن رابطة» ویستخدم للدلالة على علاقات عامة بين الكوائن؛ 
على سبیل المثالء يمكن آن پتواصل المدير مع مدير آخره ويمكن إرسال 
رسالة (من نوع ع) إلى مدير. كما إن هناك نوعاً آخر من العلاقات موضح 
في الشكل 7-6 فالخط الذي يتتهي بمعيّن مفرغ يعبر عن «جزء» من العلاقة؛ 
أو تجميع. فالكائن الذي في الطرف الآخر من العلاقة يكون «جزءاً؛ من الكائن 
الذي يشير إليه المعيّن. على سبيل المثال» في الشكل 76ء الكائن 
Crypted Payload‏ له جزء de51‏ وهو من الترع SetOfCryptoPoints‏ . 

يعطى النموذج السلوكي بواسطة مخطط تسلسل» ومثال عليه المخطط 
المبيّن في الشكل 5-6. تحدد المخططات التسلسلية جزءاً من سلوك النظامء 
وذلك بوصف تسلسل محلد للتفاعل بين مجموعة من الكوائن. في هله 
المخططات» يسير الزمن من الأعلى إلى الأسفل» بينما يظهر الشركاء ذوو 
الصلة بالنظام من اليمين إلى اليسار. تحدد هذه المخططات بواسطة الاسم 
والنوع. على سبیل المثالء الكائن ¡ من النوع هھ والکائن s‏ من النرع .S‏ 
الفترات الزمنية التي تكون فيها هذه الكوائن فاعلة مبيّنة بواسطة مستطيلات 
مركبة على خط العمر (ع«ناعنا) (الخط المتقطع). آما التفاعلات فهي موضحة 
بالأسهم ذات الرؤوس السود. كل سهم معنون باسم العملية التي يتم استدعاؤها 
لتنفيذ التفاعل على الكائن المستهدف. قد تتفاعل الكوائن مع نقسها باستدعاء 
عملياتها الخاصة» كالكائن 14عو1ء۲م في الشكل. 

آما المستطيلات ذات الزوايا المثنية فى الشكل 5-6 فهى غير مخصصة 
للمخططات التسلسلية» لكنها مخصصة للاستخدام العام فی لغْة النمذجة 
الموحدة لإرفاق الملاحظات لعناصر النموذج. كما سثرى لاحقاًء تؤدي هذه 
الملاحظات دور حاسماً في ۴٥٣84‏ في نمذجة متطلبات المصادقة. 
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1 promsgiAl) 
امع‎ 


2 :msgleu!) 


1 1 
1 1 
1 أ 
1 ۱ 
1 أ 
| ل 
1 
1 
1 
1 
1 


الشكل (6 - 5): خطوة بروتو كول لموذجية 


ForLySA 3 — 6‏ 
في هذا القسم» نصف كيفية بناء نماذج البروتوكولات بلغة النمذجة 
الموحدة» بحيث يمكن تحليلها من حيث خصائص المصادقة في إطار عملي 
مشروع 0€648. لهذا الغرض» نعرّف عدداً من حزم لغة النمذجة الموحدة 
التي پمکن إعادة استخدامها وائتي پجب أن تستخدم في Poseidon‏ » ولك 
لجعل نماذج البروتوكول قابلة للتعدبل !iتحiيJ ù .DEGAS Choreographer‏ 
ناحية أخرى» يحدد هذا القسم كيفية إنشاء نماذج تتقيلها أداة الاسشخلاص في 
نظام 184 بحيث يكون العاكس (٣هاءعااه۴)‏ قادرا على اسشخدام التغذية 

الراجعة عن المنتج. 
بعتمد التحقق الذي نقوم به على تحليل تدفق السيطرة” الذي يتم في 
PL ySatool‏ . يبيّن الشحليل ما إذا تحققت خصائص المصادقة لجميع 
محاولات تنفيذ البروتوكول التي أجربث بالتوازي مع عملية الهجوم التعسفي 
التي تسعى إلى اختراق الاتصال. يخير التحليل عن جميع الخروقات في 
خصائص المصادقة باستخدام عنصر مخصص للأخطاء. الثنائي في هذا العنصر 
(ل,٥)‏ پعني ٳذا وجد شيء مشفُر في ٥‏ فقد تم فکه في ل عن طرق کسر 
خاصية المصادقة. پتم في التحليل حساب ie coverapproximations‏ آن 
التحليل قد يبيّن وجود خطأا غير موجود فعلياً. يبيْن العرجع” أن ذلك ليس 

بالمشكلة الكبيرة عملياً. 
لعحديد بروتوكول في لغة النمذجة الموحدة بحيث تستطيم أداة 
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الاستخلاص في 84را۲٥۴‏ من توفير المعلومات للمحلل»ء يجب أن يقوم 
المصمم وقبل كل شيء بتحديد الاتصالات المقصودة والرسائل المشاركة. تحدد 
بنية كل نوع من أنواع الرسائل في مخطط رسومي مستقل يتضمن الخصائص 
الرسومية اللازمة لتحديد خاصية المصادقة. ومن ثم يجب تقديم معلومات كل 
Princip‏ كمقاتیحج الدورة وعم «منووم8 والتخزين المؤقت إضافة إلى العمليات 
اللازمة لبناء الرسائل المحللة بدقة. ثم يعرض المصمم دينامكيات البروتوكول 
في مخطط تسلسلي يحدد التنفيذ القانوني للبروتوكول. تقسم کل رسالة يتم 
تبادلها في البروتوكول إلى ثلاث خطوات: (أ) يجهز المرسل الرسالةء (ب) يتم 
إرسال الرسالة» (ج) يعالج المستقبل الرسالة الواردة. يتم وصف كل خطوة بلغة 
النمذجة الموحدة بواسطة الأسهم في المخطط التسلسلي» بحيث يرتبط كل منها 
بعملية من العمليات المستهدفة. يتم تحديد كل عملية بشروط مسبقة وشروط 
لاحقةء مثلاء لتحديد كيفية فك جزء من الرسالة المشفرةء وما الذي يجب 
التحقق منه في الرسالة الواردة آو ما الذي يجب تخزينه لاستخدامات المدير 
لاحقاً. تعرض هذه الشروط على المصمم بدلالات مفاهيم النمذجة في لخة 
النمذجة الموحدة. تعكس هذه الدلالات الدقة التي تعطيها ترجمة حسابات 
العملية ه8 . 


أخيرآًء تحدد المواقع المذكورة في خصائص المصادقة على شكل 
ملاحظات مرتبطة بالأسهم في الخطوات من 1 إلى 3 آعلاهء لتوفير الربط 
اللازم للتغذية الراجعة من عملية التحليل. هذه الملاحظات هي بمثابة موقع 
تخزين يدعم الإعلام عن الأخطاء الناتجة من عمليات التحليل. إذا كان الخطاً 
الذي أعلم عنه التحليل في الشنائي (ل )٠,‏ فإن العاكس سيعدل الملاحظة التي 
تعرف ٠‏ لتتضمن 4 لتشير إلى وجود خرق في المصادقة التي أشارت إليها عملية 
التحليل. 


كما هو مبيّن في الشكل 6-6 تفترض الأنواع والترابطات التي تحدد 
سيناريو التحقق أن آداة الاستخلاص توجد في حزمتين. في الحزمة الأولى 
ا۴ نقوم بنمذجة مفاهيم عامة كالمدراء والأساسيات والرسائل» وهكذا؛ 
أما نموذج البروتوكول الفعلي فهو مشتق موسعاً الحزمة الثانية وهي حزمة 
البروتوكول. تورث بعض الأنواع في البروتوکول من 8aر۔اإہ۴‏ بما تھا تخصص 
المقاهيم العامة للسيناريو الذي تتبعه أداة 5را , 
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For LySa 


Pratocol ا‎ 


الشکل (6 - 6) : الھیکلية العامة ل 84 را۴ 


6 - 3 - 1 التموذج الئابت 


محتويات الحزمة ۴١۲1784‏ مبيّنة في الشكلين 46 و7-6؛ في ما تعلق 
بالجوانب العامة والمدراء» وفي ما يتعلق بتفاصيل الرسائل على الثوالي. تؤخذ 
بالحسبان بروتوكولات ذات ثلائة أطراف» يكون فيها أحد أنواع المدراء كبادئ 
للبروتوكول» ويكون هناك نوع آخر من المدراء كمستجيب. إضافة إلى ذلك» 
يوجد خادم يشار إليه أحياناً على أنه طرف ثالث موثوق به أو مركز توزيع 
أساسي أو سلطة مخولةء» وهكذا. في مواصفة البروتوكول» يوجد بادئ واحد 
وعستجيب واحد وخادم واحد فقط» كما هو مبيّن من خلال الكلمة الدليلية 
المفردة في المخطط. بتواصل المدراء ويتبادلون الرسائل كما هو محدد في 
ارتياطات التواصل. للتعير عن الاتصال؛ يمكن استدعاء العملية عدص () للمدير 
الذي ترسل له الرسالة. مواصفة هذه العملية هي أنه ينسخ مكوناته إلى خاصية 
في المستقبل. بالنسبة إلى التناسق» ولتسهيل عملية الاستخلاص» نتوقع أن 
تمرر قيمة الخاصية إلى العملية عو" (). ملخص ذلك»؛ غندما سهم مدير في 
بروتوكول الاتصال؛ يجب تيع الرسالعين: (أ) الرسالة الواردة التي تتركها 
العملية عدص () في المتغير الوارد» وتطلق المساهمة و(ب) الرسالة الصادرة 
التي تبنيها العملية في المتغير الصادر؟ء ومن ثم ترسلها. 

هناك نوعان مختلفان من التشفير المقبول: التشفير المتمائل الذي 
يستخدم إما مفاتيح خاصة أو مفاتيح دورة» والتشفير غير المشماثل الذى 
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پستخدم آزواجاً من المفاتيح نهم رع عامة أو خاصة. هناك بعض العمليات 
العمومية التي يمكن استعمالها ليناء الرسائل وفتحهاء وتترك هذه العمليات 
بصورتها النظرية بما إننا ندع اخثيار خوارزمياث التشفير مفتوحاً لتخصصات 
أخرى. في الواقع؛ بتعامل التحليل مم التشفير على أنه عمليات نظرية بحيث 
لا نحصل على نتائج تحليل دقيقة من تخصيص هذه العمليات أكثر من ذلك. 
بشم تنفيذ التشفير وفك التشفير من قبل العممليثين اطا 0 راطورءءd‏ 0 
للحالات المتماثلة » أو من قيل العمليثين اورا٣ة‏ () واورءء[ () للحالات 
غير المتناظرة. نفترض أن العمليتين اطرتععل 0 واطورءء2ة () تتركان نتائج 
التنفيذ في الخاصية عاالمامورام1عطا. سنناقش نوع هذا المتغير» وهذه 
العوامل لاحقاً عندما نتناول بنية الرسائل بالتفصيل. يجب أن يتبع تنفيذ هذه 
العملياث عملية أخرى هي checkdecrypt‏ ()» كما هو بین لاحقاً. 


Msg 
Principal sen To ink: Principal 
م‎ -gink: Principal 


-sourre: Principat 


Payload‏ ا 


` GANTIES = 
سم‎ 
- orig BetofCryptoPoints 
DeeryptedPaylaad 9 [EryptedPayload 
ت‎ TT ۲ 
١ + Qes! -cantents String 
CryptoPoint 
-label String 
+ at 
ي‎ 
foriginctudas ل‎ !desllncludes 
enorypIs 


م ت 
الشكل (6 - 7): مخطط النوع للرسائل 
پمتل النوع 0دا ما يتم إرساله في أئناء التواصل وهو غير مخصص هناء 


بينما يمشل النوع ده الأعداد المستخلمة هرة واحدة فقط وتعشير هذه أداة 
فياسية عند تحديد البروتوكولات. 


كما هو مين في الشكل 76ء تحمل الرسائل (من النوع ع٥)‏ قيمة 
البيانات المرسلة الفعلية sلوەارو۳«‏ يمكن أن يكون بسضİq «CrypltedPay1loads‏ 
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آي تكون البيانات المشفرة ضمن محتوياتها. تنتج قیم CryptedPayloads‏ 
من عمليات التشفير التي أوضحناها مسبقاً. بشكل مزدوج» تترك عمليات 
فك التشفير قيما من نوع 4ئ404ء)امراءD‏ في المتغير المحلي المسمى 
tem‏ heDectryptedا»‏ وتتضمن هذه القيم معلومات واضحة في الحقل لل. 

لدعم التحليل» قد ترفق نتائج كل عملية تشفير/ فك تشفير بعناوين تسمى 
opointsاCtyp›‏ وهي (i)‏ تعرّف النقطة في البروتوكول بشكل فريد حيثما تم 
تنفيذ العملية (حسب المثال 7-6ء تم التنفيذ في الحقل )١‏ و(ب) تحدد النقاط 
التي أنشأآت فيها البياتات المرسلة الفعلية (النقطة عنعه في حالة فك التشفير)» 
أو التي ينوى استخدامها (النقطة اهن في حالة التشفير). 


إضافة إلى ذلك ولدعم التحليل دائماً يتم إرفاق كل رسالة بحقل 
المصدر ليحتوي على اسم مرسل الرسالة وحقل الهدف الذي يجب أن يحتوي 
اسم المرسل إليه 

تستخدم ılnallة check msg‏ ¢ لفتح الرسائل والتحقق منهاء بینما تستخدم 
العملية امرءءل اعمط () لفتح البيانات المرسلة الفعلية المشفرة والتحقق منها. 
سيتم تحديد الدلالات المحددة لكل استخدام لهذه العمليات في نموذج 
البروتوكول باستخدام قيود ثابتة وشروط لاحقة. سنناقش تفاصيل ذلك لاحقا 
عند التطرق للغة التخصيص. 

أخيراً» ليس هناك عمليات قياسية لبتاء الرسائل الصادرة. يجب أن تعرف 
هذه العمليات بشكل صريح حتى لو كانت مسماة بطرق معيارية» سنناقشها في 
القسم التالي» ومحددة بواسطة شروط مسبقة ولاحقة. يمكن استخدام أجزاء 
الرسائل الواردة والمخزنة فى المتغيرات المحلية بواسطة العمليات المتفذة 
schecknsg checkdecrypt / În‏ إضافة إلى معلومات محددة يعقدها الرئيس 
فى سمات خاصة. طالما أن ذلك يحدث غالباًء فإنه عند تخصيص بروتوكول 
یحتاج إلى قيمة «حديثة٠‏ من نوع ماء يعرف المدير ثلاث عمليات من نوع 
ل للتعبير عن الحاجة إلى عمل تهيئة صحيحة لبعض المتغيرات. يمكن 
استخدام هذه الفروض في الشروط المسبقة لعمليات بناء الرسالة. 


6 2-3 النموذج الديناميكي 
لتحديد بروتوكول في منهجيتناء يلزمنا تحديد آنواع البادئ الفرعية 
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والمستجيب» والخادم الذي يعرف المتغير المحلي الذي سيحمل أجزاءَ من 
الرسائل الواردة ومعلومات أخرى معيَنةء إضافة إلى تعريف عمليات معيّنة ليناء 


الرسائل الصادرة. ثم نحتاج إلى بناء المخطط العسلسلي الذي (أ) يعرض 
التكامل بين المدراء ذوي العلاقة» (ب) يحمل مواصفات كل عملية؛» على هيئة 
قيود على الأسهم. 


تشضمن حزمة البروتوكول نقطة البداية الأساسية للنشاط بطريقة تعكس 
سينارپو عملية التحقق الحالية» كما هو موضح في الأشكال 8-6 و9-6 و5-6. 
آما آسماء البادئ والخادم والمستجيب في الشكل 8-6 فتاتي من الطرق التقليدية 
غير الرسمية في استخدام البروتوكول. 


ا 


4 


Initiator 


8 5 1 B 
-kA:PrivateSymKey »kS:PrivatesymKey -KB:PrivataSym Key 
+kAp:P ublicAaymKey +kKSp:PublCASsymKey +kKBp:PublicAasymKey 
-kAm:P rivale AsymKey -kSm:PrivattAsyrn Kay -kBm:PrivateAsymKey 
-cerlA: Cer lticate -erlAinS:CryptedPayload -garlB: Cerfficale 
-rAğ Noncê -K ApinS:PubticAsymkey -<B:Nanca 
-m: info 
-prernsg1 Af: 


الشكل (8-6): مبادئ في سيناريو الشحقق 


في السيناريو» بتشارك كل مدير مع الخادم لتشفير مفتاح ممائل مع الخادم. 
تعرف هله المفاتيح الخاصة ب K4‏ و8 للبادئ والمستجيب على التوالي. إضافة 
إلى ذلك؛ پتم تخصيص زوح مفتاح غير متناظر لكل مدير. تعرف هذه المفاتيح 
ب km »k5p »kBm ءkBp ءkAn kp‏ للبادئ والمسشجیب والخادم على 
الثوالي. بشم اختيار الصفاث النهائية لهذه الأسماء لشذكرنا بإشارات الزائد 
والناقص المستعملة في لغة النمذجة الموحدة للدلالة على الخصائص والعمليات 
العامة والخاصة على التوالي. في الواقع» يتم الحفاظ على سرية المفاتيح السالبة 
في زواج المفاتيح من قبل المدير الذي يمثلكهاء بينما تكون المفاتيح الموجبة 
معرفة لجميع المديرين. وهذا متفق عليه حسب قوانين الوضوحية التابعة للغة 
البرهجة الموحلةء 
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أف اما او اتيس سره اا باو کن اة ی شای ما 
قد يقدمه مصمم البروتوكول. يتوافق الخيار المعطى هنا مع السيناريو الذي يقوم فيه 
البادئ بتشفير المعلومات وإرسالها إلى الخادم للحصول على تفويض» حيث يقوم 
الخادم بدوره بقبولها في 8«نهاءت» ويعيد التفويض إلى 4 (أي يعيد المعلومات 
المستلمة إلى 4 وهي مشفرة مع المفتاح غير التناظري الخاص ص؟ع)ء ثم یقوم ۸ 
بشخزین التفويض في المتغير شأاءء لاستخدامه مستقبلا. کما پتوقع هنا أن يقوم 
البادئ باستخدام رقم خاص rA ® Nonce‏ وجزء من المعلومات .m‏ اما 
المستجيب» فسيكون له تفويض خاص ورقم خاص. أما البنية المثالية للبيانات 
فهي موضحة في الشكل 9-6 الذي يبيّن هيكلية الرسائل النموذجية 14عء١‏ 
المستخدمة من قبل البادئ في السيناريو الموضح في ما سبق لإرسال المعلومات 
اللازمة للحصول على تفويض » وأسس التسمية المتعارف عليها للرسائل. 


س ف 
CryptedPayioad‏ 


-sink: Principal 
-source: Principal 


Msg1A 


1 theCryptedPayload1A_1 


-contents:String 


yeye | 
CryptedPayload1A_1 ا‎ Certificate 
encrypts 
DataSecure 1 DataCert 1 
-thelnfo:lnfo -P: Principal encrypts 
-k:Key 


الشكل (9-6): بنية بيانات نمطية 


(«) الرقم الخاص (ءعدهN‏ نط م٣وع‏ مام))ء هو رقم أو رمز ثئائي (011) پُستخدم لمرة واحدة فقط » غالباً 
ما کون عشوائیاً (آو ما یظهر بمظهر العشوائي) یتم إصداره من قبل بر وتو کرل ۲۳٥۸٥٤01(‏ 10۸ا یع معطاده) 
للعأكد من أن أي اتصال قديم لا بمكن استخدامه في هجوم إهادة الإرسال (عععا؟ة رعامم) هله الأرقام 
الخحاصة ختلف في كل مرة يتم فيها تقديم علهء ءوده مء مودعالمطء مها يعا٤معط‏ اداه » وكل طلب لعميل له 
تسلسل رقمي ادر» غا تبعل من هجوم إعادة الإرسال شبه مستحيل. للتاكد من آن الرقم الخاص يتم استخدامه 
لمرة واحدة فقط مبب أن يكون متغيراً مع الوقت (يحتوي على ختم وقت مناسب ومتغیر في جزء من قیمته -مصاا 
«stamp)‏ آو یتم احتسابه بطريقة معيئة E‏ الناتج هلدا من ال ٤اط‏ العشوائية لضمان وجود اإحتمال 
ضتيل جداً لإعادة احتساب القيمة السابقة العشوائية » وتقليل احتمال تكوار القيم هو متطلب اساسي 
لساب قيمة هذا الرقم إا (Nonce)‏ (المترجم). 
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آخيراًء بما أن البادئ يحمل عبء إطلاق البروتوكول» فهو يبيّن عملية بناء 
الرسائل المثالية 14عدصءءم (). هناء نتبع المتطلبات (أي أن عمايات البناء 
تحمل أسماء تدا ب ۳88١إط)‏ ونبيّن الطريقة المعيارية للتسمية (أي ترقیم 
العمليات بترتيب حدوثها تفسه ووضع علامات عليها تتضمن اسم المدير الذي 
يختص بها). تعطى دلالات هذه العملية وغيرها من العمليات بشروط مسبقة 
وشروط لاحقة - كما أوضحنا مسبقاً - وقيود ثابتة فى مخطط التسلسل»› 
باستخدام لغة المواصفات المعرفة لاحقاً. ٤‏ 


أخيرأًء يبيّن الشكل 5-6 خطوة البروتوكول المثالي»ء بوصفه نقطة البداية في 
المخطط التسلسلي. يبني البادئ الرسالة الأولى ويتم التأشير على التشفير عند حدوثه 
في 1ء4 ٤«iممهاموءء»‏ ثم يرسلها إلى الخادم الذي يزود الرسالة ب عوصععءطء 
ويفتحqا‏ ب aDecrypt‏ وcheckdecrypt.‏ يبێّن المخطط كلا crypto points pl j‏ 
التقليدي المآلوف والعناوين - أي عن طريق وضع هذا الأخير في ملاحظة ترتبط 
بالسابق. علاوة على ذلك» يبيّن المخطط الأسماء التقليدية للکوائن لهمذءماء۴ فى 
البروتوكول» تحديداً ¡ وز وه للبادئ والمستجيب والخادم على التوالي. ٠‏ 


لإكمال مواصفات البروتوكولء يجب أن يعرف المصمم رسائل جديدة» 
ويكمل كل منها بتحديد الشروط الثابتة المسبقة واللاحقة. سيتم مناقشة مواصفات 
الرسائل التي تم التقديم لها هنا بعد تقدير لغة المواصفات في القسم التالي. 


6- 3 - 3 لغة التوصيف 


إن بناء الجمل المتبع في اللغة والمستخدم لتحديد العمليات في 
البروتوكول معطى في الجدول 1-6ء حيث تبنينا الاصطلاحات الوصفية القياسية 
الآتية : الأفواس المربعة للدلالة على عناصر اختيارية» الأثواس المعقوصة لتمثل 
الحالات التي لم تحدث آو التي تتكرر أكثر من ذلك» والعتاصر ذات الخط 
الغامق تمثل الوحدات الطرفية. نحن نعطى دلالات لغة التوصيف بشكل غير 
رسمي» كما سيأتي. سندعو الكائن الذي يستهدفه السهم بوجهة العملية وهو 
الكائن الذي ترتبط معه عملية معيّنة. 


المواصفة ءعم8: تقيم كل مواصفة ب ءعوموعصه× الذي يدمج أسماء 
عثاصر العملية مع eمدpوء”4×‏ لمخطط لسلسل الذي يحتوي على أسماء 
الكائن (¡ وز وة) ويدمجها مع Namespace‏ للوجهة. إذا كان الاسم يشير إلى 
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كائن» فإنه بمكن الوصول إلى الحقول التي تثبع له أيضاًء وهكذاء بشكل 
متكرر»ء بالطريقة المعتادة. علاوة على ذلك» يتضمن تقييم #٥مصءءةN‏ جميع 
المفاتيح العامة المعيارية ص×k.‏ عندما تكون الوجهة عبارة عن خادم؛ سيتضمن 
ıa Namespace‏ المفاتيح الخاصة المناظرة ×k»ء‏ بما إن الخادم يعرفها 
جميعها حسب هذا السيناريو. المصمم مسؤول عن غياب التعارضات 
(#عطووا٥)؛‏ لكن من شأن اصطلاحات التسمية أن تسهل هذه المهمة. 


الثابت 1«۷: يمكن آن برتبط الثابث مع عوصعععطع للتحقق من الرسائل 
الراردة أر اورrءCheckde‏ للتحقق من نتاٿج فك التشفير. الهدف من وجود 
#تابٿة هنا هو شرط وجوده نتفه على الرسائل في لغة النمذجة الموحدة» إذ 
يعمل على حجز البروتوكول إن لم ۾ يبحفق الشرط. من الواضح أنه في النسخة 
العامة من نظام Poseidon‏ لم توفر شروط ضمنية للرسائل في مخططات 
الشسلسل في ناء بناء المصمم عطمة٣عمءإمط)»‏ لذا توجهنا نحو ذلك التحوّل. 
القيد الوحيد الذي يمكن فرضه في المتغير هو أن قيم طرفي الشروط مثساوية. 


الجدول (6- 1) 
ت ركيب لغة التوصيف 


Spec::= Inv | Pre | Post | Comment 

Inv:i= Cond f, Cond ; 

Pre::= TypeRestriction | EncryptedType | 
Initialization ¢ & Initialization î 

TypeRestriction::= lde: Type 

EncryptedType:: Ide encrypts DataConstructor 
Initialization::= isNewKey ( Ide } | isNewInfo { Ide } | 
isNewNonce { Ide } 

Post::= [ with TypeRestriction ] Cond ; & Cond | 
Cond::= Name = Expr 

Name:.:= Ide f. Ide } 

Exprii= Nane | Fun ( [ Expr { . Expr | ] ) 

Funii= crypt | aCrypt | cep | Constructor 

Ide::= <any name defined in the namespace of the destination 
Constnuıctori:= SetofCryptpoints | Data onstructor 


Data onstructor::= “any data constructor# 
Comment = $f efinur f 
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غالبا ما يتم التحقق من المصدر وقائمة انتظار التجميع في كل رسالة 
مقابل القيمة المتوقعة. يمكن إجراء عمليات تحقق إضافيةء لكن ذلك يعتمد 
على تحديد البروتوكول؛ مغلا يجب آن تكون البيانات المرسلة الفعلية 
الواضحة مساوية لعدد مصادر الرسائل - أي إن الطرف المرسل يمكن أن 
الجهة المقصودة فعلاً. هذه التحققات تجعل البروتوكول أكثر قوة وتمنع أي 
اختراقات خبيثة في فترة التنفيذ. 
الشرط المسبق :۲٣١‏ يجب أن يرتبط الشرط المسبق مع كل استدعاء 
للعملية عو" ()» وذلك لتحديد نوع الرسالة الحالية الفعلي بواسطة قيد للنوع. 
کما یچب أن يرتبط شرط مسبق مع کل عملية اpرcdecrypt/aDecr‏ وذلك 
لتحديد نوع البيانات المشفرة بواسطة بيان خاص بالبيانات المشفرة. أخيراًء تتيح 
الشروط المسبقة للمصمم التعبير عن حالات البدء وص0ناوعالهانم! الموجزة في 
Premsg‏ (راجم ما یرد لاحقاً). 
التهيثة «0ناةناونانم1: المعتى المقصود هنا هو آنه قبل تحديد عملية 
معيْنة» يكون قد خصص لعتاصر هذه المسندات (وعاهعاله۴۲) قَيّم جديدة. 
یمکن استخدام التهيئات لهذا الغرض لتمثل الشرط المسبق لعملية ren‏ . في 
ما يتعلق بالتحليل» فإن غياب التهيئة الملائمة سيقود غالباً إلى كشف المزيد من 
الأخطاء نظراً إلى آنه يترك بعض القيم غير محمية. 
إن اختيار العوامل في التهيئة يعكس مجموعة من الافتراضات في ما يتعلق 
بالمفاتيح : 
- المفاتيح الخاصة» إما أن تكون متماثلة أو غير متمائلة» يمكن 
استخدامها بحرية في العمليات الخاصة بالمالك» حيث يفترض أنه 
يمكن تهيئتها قبل بدء البروتوكول. 
- المفاتيح العامة غير المتماثلة يمكن أن تستخدم في آي مكان نظراً إلى 
طبيعتها. لكن قد تقيد بعض البروتوكولات تفسها لاستخدام المفاتيح 
العامة التي قد تم تبادلها بشكل صريح. 
- مفاتيح الدورة يجب أن يتم تهيثتها قبل استخدامها. 
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يجب أن يتم تهيئة الرقم الخاص وأي معلومات يتم انتاجها وتبادلها في 
أثناء تنفيذ البروتوكول قبل استخدامها. 

الشرط اللاحق .ا١٥۴:‏ يستخدم الشرط اللاحق لتحديد تأثير عملية معيّنة 
فى حالة الوجهة المستهدفة. الشرط اللاحق للعملية عو هو قياسى» تحديداً 
١م‏ = صن وهذا يعني آنه يتم نسخ الرسالة المرسلة (قيمة العنصر ص المخصصة 
هى قيمة الخاصية اه للمرسل) إلى الخاصية ١1ا‏ للمستقبل. 

فى حالة الشرط المسبق re8‏ نستخدم عادة عنصراً اختیاریاً وهو هتا 
عنصر فتح نطاق السجل» لا تحتاج الحقول إلى أن تكون مسبوقة بالمعرّف» 
في الطرف الأيسر من الشروط التي تتبعها. القيد هنا هو (u1:52Mه»‏ إذا كانت 
العملية هى “premsgM‏ . وهذا يستلزم أن تكون أسماء البيانات المرسلة الفعلية 

التأثير المقصود من هذه العملية مبيّن فى الشروط المبيّنة الآتية. 

الشرط 4«ه٣:‏ عند استخدام الشرط في ثابت» فإنه يعبر عن حالة 
تحقق» كما هو مبيّن أعلاه. عند استخدام الشرط المسبق» فإنه يعرف فيمة 
الخاصية أو أحد الحقول كنتيجة لتنفيذ العملية التي يحددها؛ يدل الاسم في 
الجانب الأيسر على العنصر الذي يأخذ القيمة المعرفة في العبارة الموجودة 
في الطرف الأيمن. 
على الوصولية إلى حقول الكائن: على سبيل المثال» يشير 1.× إلى أن المتغير 

التعبیر ۴×۳۴: يشير التعبير إلى متغير. يستخدم رمز النقطة المعيارية للدلالة 
على الوصول إلى حقول الكائن: على سبيل المثالء يشير 1.× إلى آن القيمة 
ممثلة ب 1 فى موقع الاسم الخاص بالكائن بدلالة ×. 


المعرّف ل1: يشير المعرّف إلى قيمة أو متغير اعتماداً على السياق ويقييم 


(1) جب أن يظهر القيد نفسه كشرط مسبت في عملية ودن اللاحقة. 
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- تقييم عوامل العملية بالنسبة إلى العناصر المناظرة لها كما هو محدد في 
مخطط التسلسل. 
- تقييم المعرّفات في مخطط التسلسل بالنسبة إلى الكوائن المناظرة لها. 
- تشير خصائص كائن (بما في ذلك الكوائن المعيارية) إلى الكائن أو 
القيمة المناظرة حسب نوعها. 

- تقييم أسماء المفاتيح الأساسية حسب المفتاح المناظر لها. 
Namespace‏ عتد مشأ السهم. 

ص۴ : تتضمن العمليات التى يمكن قبولها إجراءات التشفير وإنشاء البيانات 
التي سيتم تشفيرÎk‏ وijڎlء Cryptopoints le geجag Cryptopoints‏ , باتباع 
الجافاء يكون مح المنشئ اسم نوع الكوائن اتی يجب بناؤها. يجب أن تتوافق 
العناصر مع حقول النوع فى العدد والترتيب. أما عتاوين sاصاهمهامرء)‏ فتكون 
ضمن مصرح بها ضمنياً» ویستخدم cp‏ ک|-ختضصر CryptoPoint J‏ . 

قبل أن نتناول مثالاًء علينا أن نذكر بعض العمليات المعيارية واصطلاحات 
التسمية المتبعة فيها. 

الرسائل sءعaووء:‏ يچب أن تکون الرسائل من النوع «MsgM‏ حي M‏ 
هو رمز فريد لبنية رسالة معطاة. يجب أن يتم تسمية البيانات المرسلة الفعلية 
»theCrypted Payload ZK thePayloadY 4‏ حیث ¥ وz‏ يضیمفان إلى الرمز ١‰‏ 
رقماً يبن ترتيبه في الرسالة. 

البيانات ٥1a‏ : يجب آن تكون البيانات المشفرة من نوع »0414٥M‏ حيث 
M‏ هو رمز فريد لبنية معطاة من البياتات. 

المدراء Principals‏ : یچب أن يکون لكل مدير علد من عمليات 
Prem‏ بعدد الرسائل التی پڀرسلهاء حيٹ M‏ هو نوع الأرسالة المرسلة نفسه. 
يجب أن يتم تسمية عناصر كل عملية (إن وجدت) على النحو p2 p1‏ . 
حسب ترتیب ظهورها. أا کوائن المدير فيجب أن تسمی 1» ز» 8. 
هو »٣‏ حیٹ ×م1cp:‏ يجب أن يتم تسميتها بطريفة معياريa‏ : Cryptopoints‏ 
نوع المالك»ء و× هو عدد تصاعدي. 
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الجدول (6- 2) 
نموڏج سردي 


1:premsglA () $$ A -> S$: LA,kAp KSp 35 
<postcondition7: with out:Msgl A source =1 & sink = s & 
theCryptedPayloadll A_1.contents = acrypt {(kSp,DataCert (,kAp) } & 
theCryptedPayloadl A_1 dest = Setofryptpoint (Scp I} & 
theCryptedPayloadlA_1l.at = cp (AcpI|) 

3:mss (out) 

<precondition7: out: Msu | A 

<postcondition?: in = p 

3:checkmsg (} $3 A -2 S: (A.kAp f :kSp $5 

<invarlant?: I.source=l, in.stnkz=s 

<postcondition?: certAinS contents = 

in. theCryptedPayloadl1 A_1 contents 

4:aDecrypt (kAp.certAinS.contents) 

<precotditon?: certAinS encrypts DataC ert 
<postcondition?: theDecryptedltem.at = cp {Scp1) & 
theDecryptedltem.orig = SetofCryptpoint {(Acp) 


5:checkdecrypt Û 


<inyvariant>: the Decry ptedItem.dd.p=1 
<postconditionz: kAplnS = theDecryptedItem.dd.k 


6 - 3 - 4 مثال على مواصفة العملية 


لمناقشة استخدام لغة التوصيف» نستغل المخطط الموضح في الشكل 1-6 
والسرد المبيّن في الجدول 2-6» الذي پعرضس جميم الشروط المرتبطة بالعمليات 
في النموذج» ويمكن إنشاؤها أوتوماتيكياً على هيئة المصمم Choreographer‏ 


هن نموذج لغة النمذجة الموحدة الموضحة في ما سيق“ . 


بمكن التعبير عن الجزء المخصص للبروتوكول الذي تناولناه هنا بالأسلوب 


غير الرسمي المستخدم لمنافشة القضابا المتعلقة بالتشفير على الصورة 
A- * S$: {A, kAp}: kSp‏ 


(«) خاصية المصمم مطمعوءمط هله مفيدة جداً عند تتيم أخطاء النمرثْج وتصحيحها. في الواقع ء 


ارتبطت هله الشروط بالأسهم في المخطط من خلال أطراف الإدخال/ الإخراج في عرر النموذج» ويمكن 


فحصها على حدة فقط + بحيث بكرن من الصعب تكون تصوّر شامل هن الواصفة (الترجم). 
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للتعبير عن أن البادئ 4 يرسل رسالة إلى الخادم 5 وهو يتکونك من 
الزوج› ح اسم البادئ ومفتاح البادئ العام > مشفرا ت مفتاح الخادم العام. ك 
حقيفة كون التشفير غير المتماثل المستخدم یبقی ضمنياء بناءَ على اسم المفتاح. 
وتبيّن أن وصف هذه الخطوة كخطوة شائعة في العملات التي تبني وتستلم 
الرسائل هي طريقة مفيدة جداً لتوثيق البروتوكول. إضافة إلى اسم ورقم كل 
عملية» تعرض كل مدخل في الجدول 2-6 يعرض المعلومات الآتية عند 
توفرهاء وذلك لکل سهم في المذطط التسلسلي : التعليق من حقل «التوثيق) 
متضمتا برمز الدولار مزدو جا وحقول القيرد مرتبطة بتوعها, 

تعمل العملية الأولى في هذه الخطوة من البروتوكول (14عء”۳ءإم) على 
بناء الرسالة التي يكوك نوعها 5814 كما هو مصرح به في قيود النوع في 
الشروط اللاحقة وهى تتطلب تعريف الحقول الخمسة الاآتية : 

8 مصدر الرسالة» ویحمل هذا الحقل اسم کائن البادئي» 1 

® حقل 44ه0ارة 4۴هام المعياري ومحتوياته» ويحمل هذا الحقل نتيجة 

فك تشفير غير المتمائثل مع مفتاح عام للخادم a‏ وبیانات DataCert bai‏ 

(بثاء على ما هو مصرح به في الشكل 9-6 من قبل رابطة التشفير). أما 

حقول البيانات المشفرة فهي» كما هو معرّف آعلاه» اسم البادئ والمفتاح 

العام. 

e‏ حقل CryptedPayload‏ المعياري› والاتجاه» ويحمل هذا الحقل 

Cryptopoint‏ مرتبطة مع مكان فك التشفير المقصود» الذي يحلدده المصمم 

ب 5P1‏ حسما ورد فی الشكل 5-6 . 

© حقل CryptedPayload‏ المعياري ويحمل هذا الحقل «Acp1‏ 

اinەpتاPرا‏ المرتبطة بهذه العملية فى الشكل 5-6. 


المدخل الثانى فى الجدول 2-6 هو معياري»› وپوفر جمیح المعلومات 
اللازمة لتحديد النقل من الخارج في البادئ) إلى الداخل فى الخادم. 

آما المدخل الثالث فهو يكرر التعليقات؛ وهذا أمر مفيد للمصمم الذي قد 
يلقي نظرة على شيفرة [8a‏ المنشأة. وحیٹ إنù Checkmsg yı Premsg‏ لم تعد 
متجاورةء فإن التعليقات التي يخبر عنها في شيفرة 54ا تساعد في ربط القطع 
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بعضها ببعض. تالياً» يعبر الثابت عن أنه قد تم التحقق من حقول الرسالة 
المعيارية والمصدر وقائمة انتظار التجميع› وذلك للتأكد من آنها ما يتوقعه 
المصمم. 
إضافة إلى ذلك يؤكد الشرط اللاحق على أن الجزء المعلوماتي من 
oadاedayاypا‏ للرسالة الواردة يخزن في المتغير المحلي 5Sمنهاءمت‏ لإجراء 
المزيد من المعالجة. آما الحقول الأخرى اي#ل واه فهى ليست ذات صلة هنا. 
أما المدخلان الأخيرانء» فيجب مراعاتهما معاً وذلك آنها يتعاونان في فتح 
dعهاره۴‏ المشفر والتحقق من محتوياته ومن أجزاء التخزين كمرجع مستقبلي. 
يجب أن يعلن الشرط المسبق للعملية رقم 4 عن النمط الفعلي للحقل لل 
للمتغير المحلي الذي يقبل نتيجة فك التشفير ا !لءامرءبءطعطا. أما الشرط 
اللاحق للعملية نفسها فيعرّف الحقول الأخرى» وهي : 
© الحقل الذي يعنون نقطة فك التشفير اه التي تأخذ القيمة 1م85 حسب 
الشكل 5-6. 
8 الحقل الذي ينص على المنشأً المتوقع» أي موقع التشفير» ويأخذ 
القيمة p1ءة.‏ 
يعرف المدخل الأخير حالات التحقق من نتيجة فك التشفير (نعطلب أن 
يكون مدير التحويل هو البادئ نفسه) وأن يكون المفتاح مخزناً محلياً 
لاستخدامه لاحقاً من قبل الخادم لبتاء التخويل للبادئ. 


6 5-3 الانعكاس 


نناقش الآن باقتضاب كيفية عرض نتائج التحليل على المصمم. يبيّن 
الشكل 10-6 نتائج انعكاس الإصدار المتدفق من برتوكول «الضفدع ذي القم 
الواسع“" الشهير. يصف البروتوكول التغير الأساسي بین مدیرین ۸ و8 خلال 
خادم موثوق به. هناك ثلاث خطوات للبروتوکول : 

1. یرسل المدیر ۸ رسالة إلى الخادم تتضصمن اسم B‏ ومفتاح الدورة 
مoاووعو‏ الجديدة ورک وتكون هذه المعلومات مشفرة مم المفتاح العام .Kas‏ 


(«) يمكن مطالعة تفاصيل عن هذا البروتوكول بالرجوع إلى الموقع الإلكتروني : .منلعواعذس.مء//:1pاط‏ > 
org/wiki/Wide_Mouth_Frog_protocol> ,‏ 
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2 بقوم الخادم يفك تشفر المعلوماث ویرسل اسم ھ والمفتاح الجديد Kan‏ إلى 
إلى +B‏ وتکون هله المعلومانت مشقرة جن المفتاح العام Kas‏ الخاصس E‏ 


Rast i ۱ 
ù ~4 Acp1, Scpl b 
: msg (ou) Sa ١ 


:checkmsgi) 


:postmsg1S fn.source) 
ل‎ : 


۹ :checkdecrypt (} : 
1 


msg2$ {s, in, he Payload1 _il resp) 
3 


1 
۳ 
msg (out) 
n e  «checknsgÛ 


:poslmsg2B {) 


Bep1 :checkdecryptl) 


'  msg30i_i.rml 
1 
1 


ل[ 


:msg'{out) 
8 


c 
:checkmsgt) 


:posimsg3B) 


:checkdecrypt() 


الشكل (6 - 10): مثال على مخرجات عملية التحليل 


في أثناء تحليل هذا اليروتوكول»ء تعمل الأداة على إيجاد الأخطاء 
المحاطة بدوائر في الشكل 6 - 10. على سبيل المثالء إن فك التشفير عند 
2 قد يفك تشفير الرسائل الواردة من مهاجم (یرمز ها ب ۳۲5۷) بدلا من 
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فك تشفير الرسالة الواردة من Acp2‏ فقط کہا پجبه. بثاء على هذه الأخطاءء 
النمذجة الموحدةء ويعيد تنفيذ التحليل إلى أن يضمن المحلل عدم وجود أي 
أخطاء في البروتوكول. 


6- 6-3 الخبرة 


إضافة إلى الأمثلة الصغيرة المستخدمة لاختبار الأدوات تحققت خبرات 
واسعة فى مجال منهجية التحقق فی مشروع DEGAS‏ مع العديد من دراسات 
الحالة. كان ثمة اثنتان منها قدمها شركاء صناعيون. 


دراسة الحالة الأولى هي عبارة عن لعبة فيديو يمكن أن يلعبها عدد كبير 
من اللاعبين في الوقت نفسه في سياق شامل وبيئة مفتوحة. هناك خادم رئيس 
مهمته الرئيسة التنسيق فحسب» حيث تتم التفاعلات بين اللاعبين مباشرة بين 
أجهزة الهواتف الخلوية على أساس نظير - نظير»ء من خلال ترابط البيانات 
أو الرسائل القصيرة. من الضرورة بمكان أن يتم التواصل بين اللاعبين» وبين 
كل لاعب والخادم بطريقة آمنة لتجنب إمكانية أن يغير المهاجمون متغيرات 
اللاعبين والكوائن التي يجمعوتها في أثناء اللعب. نظراً إلى طبيعة النظير - 
التظير الخاصة بالمشروع؛ يجب على البروتوكول «الأمان» أن يقلل من تدخل 
الخادم. 


أما دراسة الحالة الثانيةء فتتضمن خدمة تعمل من خلال الويب لتمكين 
تنفيذ الأعمال الإلكترونية الجزئية بناء على المصادقة نظير - نظير ونموذج 
التواصل. والهدف من ذلك توفير آلية تجارة إلكترونية نظير - نظير بسيطة 
لمجموعة المشترين والبائعين» عن طريق عرض تسهيلات الأعمال من خلال 
الويب للبائعين الذين ليس لديهم مصادر لتطوير حلول امتلاك كما أنها 
تعرض وصولية سهلة لمعلومات المنتجات والخدمات للبائعين. تتم معالچة 
التحويلات المالية بواسطة خدمات بنكية. يجب أن يكون التواصل ممكناً من 
خلال اتصالات الإنترنت السلكية ومن خلال الأجهزة الخلوية باستخدام 
بروتوكولات كبروتوكول التطبيقات اللاسلكية ۷۸4۴ . يمكن تقليل متطلبات 
الأمان لدراسة الحالة هذه لتأسيس موثوقية للرسائل» التى تعتبر خاصية الأمان 
الرئيسة في مشروع ٠ . 5٤6۸5‏ 
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في كلتا الحالتين» من المفضل استخدام التشفير المتناسق للتبادل نظير - 
نظير بين الأجهزة الخلويةء طالما آن الحمل الحاسوبي لها أصغر مما ني 
التشفير غير المتناسق. لكن يجب أن تكون المفاتيح التي سيتم استخدامها 
محمية من الدخلاء الماكرين. لذاء ابتكر بروتوكول مكوك من جزئين: 
أحدهما يتضمن مفاتيح عامة موزعةء والثاني يتفق فيه زوج من اللاعبين على 
استخدام مفتاح دورة. تبيّن التحليلات أنه يجب استخدام وسائل أخرى 
لتأسيس موئوقية للرسائل؛ يجب أن يفوض كلا اللاعبين بعضهما بعضاً بهدف 
منع أي جاسوس من إدخال المفتاح الخاص به بدلاً من المقتاح العام لأحد 
اللاعبين. 


البروتوكول الناتج يدعى 4٥٥۵5ءںءم5»‏ وله مخطط تسلسل ذو 38 سهماًء 
وقد تم تحليله بنجاح في مصمم Choreok ta phe‏ . هذا ویمكن الرجوع لمزيد 
من التفاصيل إلى المراجم؟' و"". 
6 4 الاستنتاجات 

إن الهدف الإجمالي لعملنا شبيه بعض الشيء ء بهدف أطر العمل ك 
AVISS gy PCVSy PCAPSL,y Casper‏ . تهدف أطر العمل هذه جميعاً 
إلى تزويد المطوّرين ببروتوكولات الأمان ببيّنات متقدمة لأدوات التحليل؛ لكن 
وخلافاً لمنهجتاء فأطر العمل هذه ترتكز على الملاحظات المخصصة. من 
ناحيةء قد يودي ذلك إلى وصف أاكثر إحكاماً للبرتوكولات من وصفنا؛ لكن 
من ناحية أخرى» لدينا كافة مزايا استخدام لغة النمذجة ذات الأغراض العامة. 
فمن الناحية التقنيةء المعلومات الموجودة فى أوصاف البروتوكول فى أطر 
العمل المذكورة أعلاه شبيهة بالمعلومات الملتقطة فى مخططات تسلسل 
الرسائل خاصتنا. إضافة إلى ذلك» نجد بعض التشابهات على وجه الخصوص 
في نظام pe‏ الذي له تشکيل تحليلي للهدف باستخدام عملیات تفاضل 
وتكامل. عملية الفلترة التي تتم في إمموه أبسط من عمليتنا لأن لغتها 
المتقدمة مصممة بحيث تتضمن مباشرة عمليات معالجة للتعبيرات الحسابية فى 
أماكن مريحة. 

ثمة جهود مهمة تتشارك في مشروع 0۴648 تركز على لغة النمذجة 
الموحدة وهي مركزية فى مو1 0M‏ . وهذا عبارة عن ملف بلغة النمذجة 
الموحدة للتعبير عن معلومات ذات صلة بالأمان ضمن المخططات في 
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مواصفات النظام» وني المتهجية المرتبطة بتطوير نظام آمن" . يتيح M1460‏ 0ا 
للمصمم التعبير عن متطلبات الأمان متكررة الحدوث كالتبادل المباشر والأمان/ 
السرية وتدفق معلومات الأمان ورابط التواصل الآمن. ثمة قراعد للتحقق من 
صحة نموذج من حيث متطابات الأمانء استناداً إلى دلالات أساسية لجزء لغة 
التمذجة الموحدة المستخدم. يتيح لتا هذه الأساس الدلالي على وجه الخصوص 
التحقق مما إذا كانت القيود المرتبطة بقوالب لغة النمذجة الموحدة النمطية 
متحققة بمواصفات معيّنة. العمل جار لترفير دعم تحليلي أوتوماتيكي»› بمنهجية 
شبيهة بمنهجية نظام .0۴E6G48‏ برآينا» يوفر نظام 83ء٥۴‏ طريقة أكثر حدسية 
للتعبير عن متطابات المصادقة أقل مركزية فى ٥٥ا0‏ : إذ يجب أن يكون 
تقیيم جدوى الاندماج بين المنهجيتين أمراً مجدياً. 


إن الخبرة المكتسبة في العمل على دراسات حالة في مشروع 5٤6٥۸5‏ 
تقترح آن تقديم بروتوكول التحليل الذي رأيئاه أعلاه مفصل جداً حتى لا يبدو 
مستخدماً بكفاءة عند استثمار البروتوكول في تصميم تطبيق ما. يجب أن يكون 
المصمم قادراً على استخدام بروتوكول في تطبيق ما بسهولة حالما يتم تفويضه. 
أساسياًء لا يرغب المرء برسم أكثر من سهم لكل خطوة في البروتوكول» عند 
تصميم تطبيق» أو قد يرغب في تحديد بعض المعلومات المتبادلة فحسب 
باستخدام البروتوكول. آما أفضل طريقة لربط هذه العروض المختصرة والكاملة 
للتحليل فقد تركناها لمزيد من الأبحاث. 

من القضايا الأخرى المفتوحة واحدة ترتبط بتنفيذ البروتوكول. فمن 
المعروف أن عملية التنفيذ يمكن أن تؤدي إلى عيوب» حتى لو بدأنا من 
مواصفة صحيحة مثبتة. الآن وفي حالتناء تتضمن المواصفة المستخدمة لتحليل 
البروتوكول معلومات كافية لدعم التنفيذء والهدف المتمثل في اشتقاق التنفيذ 
الصحيح أوتوماتيكياً يستحق السعي وراءه. 

الحل المستخدم للإبلاغ عن معلومات الخلل عند مستوى لغة النمذجة 
الموحدة هو حل معتدل بعض الشىء ويمكن جعله ممكناً عن طريق حقيقة أن 
المخطط يحصر بحيث يوفر تثبيتاً للإدخال: أي الملاحظات المرفقة مع الأسهم. 
على كلٌ» يبدو هذا الاععدال تبادلاً جيداً إلى أن يتم تبادل المستحقات في 
مخطط لخة النمذجة الموحدة المعياري المتطورة. في الواقعء لا يبدو أن 
بذل الكثير من الجهود في حل عروض رسومية محددة لمخطط بيئة نمذجة 
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واحدة آمر مجدٍ. فحالما يكون المعيار متوفراً» سيكون مجدياً تصميم خوارزمية 
لتحديث المخطط بإضافة نتائج التحليل بطريقة أكثر مرونةء والتي ستكون لها 
شرعية عامة ضمن المعايير. 

الاستنتاج» نتذكر أن العمل الذي ورد هنا كذلك الذي ورد في التحليل 
الكمي هو أيضاً مضمَّن في المصمم Choreographer‏ وهو نوع من الهجوم 
قصير الأمد للمشكلة الموضحة في المقدمة - أي أنه يتم صقل تأثيرها السلبي 
في عملية التطوير لمنتهجيات واسعة من خلال واجهة لغة النمذجة الموحدة. 


على المدى الطويل» يمكن حل المشكلة بواسطة هجومات متقارية تتضمن 
جميع اللاعبين في اللعبة: يجب أن يتم الاستثمار أكثر في البحث والتطوير وفي 
تدريب العاملين» بحيث لا يعود السلوك الشكلي مثبطا لهمة المحترفين» كما 
يجب أن يعلم الأكاديميون المهندسين للبدء بها ويجب أن يستهدف البحث 
تكاملاً أساسياً لنظريات متنوعة تختص بالمواصفات الأساسية. 


شکر وعرفان 

أفاد هذا العمل من العديد من الحوارات التي دارت مع العاملين في مشروع 
«DEGAS‏ في أثناء الاجتماع بهم في بيزا وترينتو وإدينبرة. نوجه شكراً خاصاً 
لکل من تشیارا بودیه (eiل80‏ raھنطح(«‏ بیرباوgi «(Pierpaolo Degano) gil‏ 
ومیخائیل بوتشولتز (o12ططcںB‏ 1٥هMk)‏ وذلك لتعریفتا بنظم ¢LySa's arcana‏ 
نشكر أيضاً ميكاييلا فاساري (Monika Maid1) Jı ıa (Michela Yasari)‏ 
لبصيرتيهما النافذة فى بروتو كول دراسة حالة» ونشکر لازا بیرونٰ (ع٣‏ 0٣۲ء۴‏ a٣aا)‏ 
وسيموك سيمبر يني (Daniele Picciaia) lılتب aıilag (Simone Semprini)‏ 
لبرمجة آداة الاستخلاص» وفال هاينيل (¢1” )¥a1 ae‏ لدمج آداة الاستخلاص 
مع Choreographer‏ وبناء العاكس. 
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تطوير تطبيقات الويب الحديثة 


مهدي جزائري (Mehdi Jazayeri)‏ 
وسيدرياك میسناج (Cédric Mesnage)‏ 
وجیفري روز (ع9ه۸ ۴۲y]مل)‏ 


7- 1 المقدمة 

عرف العالم شبكة الويب العالمية عام 1994ء التي كانت تهدف إلى إتاحة 
الوصول إلى المعلومات من أي مصدر بطريقة سهلة ومتسقة. هذا وقد تم ذلك 
في المنظمة الأوروبية للبحث النووي C8۸۸‏ في جنيف في سويسراء وقد كانت 
هذه الشبكة هدف الفيزيائين وعلماء آخرين ممن ينتجون كميات هائلة من 
النصوص التشعبية كطريقة سهلة لإعطاء وصولية للوثائق وربط بعضها ببعض. 
بروتوكول نقل النصوص التشعبية ۸1١۴‏ مصمم لإتاحة المجال أمام أحد أجهزة 
الحاسوب - حاسوب تابع - من طلب البيانات والوثائق من جهاز حاسوب آخر - 
بهذه الطريقة» استعرضت شبكة الويب العالمية کمستودع واسع للمعلومات التي 
توفر وصولية بعدد كبير من المستخدمين. لقد تطورت الويب كمستودع ثابت 
إلى حد بعيد بمرور الوقت. آما الآن» فالويب عبارة عن منصة معقدة تعرض 
طائفة ضخمة من الأدوات والمكزنات لمطرري التطبيقات. ثمة جيل جديد من 
التطبيقات يوفْر للمستخدمين فرصا للتواصل والتشارك وتحديث إمكانيات 
تطبيقاتهم. تدعم التطبيقات الأعمال الصغيرة أو المجتمعات الصغيرة من 
المستخدمين » إضافة إلى أعمال الشركات الكبيرة. 
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يستمر الويب في التطور بوتيرة متسارعة. هناك العديد من الأفكار عن 
التوجهات التي ستسود في المستقبل. ثمة مفهوم الشمول الكامل يراعي 
الاتجاهات الحديثة كصياغة أساس الويب الإصدار 2.0. وبمقارنتها بتطبيقات 
الويب التقليدية» كانت تطبيقات الإصدارين 1.0 و2.0 ديناميكية أكثر وكانت 
تستدعي مشاركة المستخدم» وكانت مستجيبة لطلبات المستخدم كما هو الحال 
في تطبيقات سطح المكتب. قد يكون أفضل وصف للويب إصدار 2.0 هو ذلك 
الذي O’Reilly < http://www.oreillynet.com/pub/a/oreilly/tim/news/ aan‏ 
.2005/09/30/what-is-web-20. m1 >‏ يقارن هذا المقال التطبيقات والتقنيات من 
الويب 1.0 والويب 2.0. من الأمثلة التى يطرحها البعض: ويكيبيديا مقارنة 
بالموسوعة البريطانية» حيث ربط فيها المؤسسون مساعدة المستخدمين بإنشاء 
بیانات رسم» ثم بعدئد رسم علامات تمييز واضحة بين منتجي ومستهلکي 
البيانات. مثال آخر على ذلك النشر في المواقع الإلكترونية مقارنة بالتدوين 
التي تختلف بطرق العرض التي تتيح مشاركة المستخدمين. كمثال ثالث» يمكننا 
احترام استخدام محركات البحث للعثور على المواقع اللإلكترونية خلافا للطرق 
السابقة التي كانت تحتم على المستخدم تذكر آو تحزير عناوين المواقع 
الإلكترونية. ما الذي جعل النسخة 2.0 من الويب ممكنةء وما هو التالي؟ 


في هذا الفصل» ننظر إلى حالة المهارات والمفاهيم المهمة التي تقح 
ضمنها ونستحث تطوير الويب 2.0» وآخيراً التوجهات القادمة في تطبیقات 
الويب» ودعم البئية التحتية الضمنية. 


7 2 اساسیات الوب 


على الرغم من التطورات الهائلة التي حدثت في العقد الأخير» ظلت 
المبادئ الأساسية التي قامت عليها الشبكة العالمية ثابتة. من الثاحية الهيكلية› 
الخوادم الوثائقء بينما تعمل الأجهزة التابعة على الوصول إلى هذه الوثائق. 
هذا وقد يكون جهاز الحاسوب تابعاً أو خادماً في أوقات مختلفة. قدمت 
شبكة الويب العالمية ثلاثة مفاهيم أساسية عن الحوسبة التابع - الخادم» 
وهي : طريقة تسمية الوثائق والإشارة إليها (محددات مواقع المصادر الموحدة 
ا لغة لكتابة الوثائق التي تحتوي على بيانات وروابط لوثائق أخرى 
(لغة ترميز النصوص التشعبية ا11M1)‏ وطريقة لتواصل أجهزة الخوادم 
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والتوابع مع بعضها بعضاً (بروتوكول نقل التصوص التشعبية .)۸١١۴‏ 


محدد مواقع المصادر الموحلدة URL‏ : النظام المسمى هو المكوْن 
الأساسي للنظم الحاسوبية» مخصص للنظم الموزعة. يصف النظام المسمى 
طريقة تسمية الكوائن بحيث يمكن تعريف هذه الكوائن وتحديد مواقعها. اعتمادا 
على خصائص التظام المسمی» يمکن البحث عن الکوائن على آساس آسمائها 
الدقيقة فقط» أو على أساس مواصفاتها. على سبيل المثال» قد يرغب أحدهم 
في إخبار النظام ب «ابحث عن الوليقة التي كتبها آلان تيرنينغ وموضوعها 
الاختبار الذكي). تهدف طريقة التسمية في شبكة الويب العالمية إلى تحديد 
الكوائن المخزنة في الحواسيب المرتبطة بشبكة الإنترنت تحديداً فريداً. ترتكز 

يقة التسمية على محددات مواقع المصادر الموحدة 0۸1 وهي أسماء مركبة 

تحدد الحاسوب (آي عنوان بروتوكول الإنترنت) والوثائق في نظام الملفات في 
ذلك الحاسوب. تعرّف محددات مواقع المصادر الموحدة الآن كمعيار في 
المذكرة 1630 „IETF RFC‏ 

لغة ترميز النصوص التشعبية 111: تكتب الوثائق على شبكة الويب 
بلغة ترميز النصوص التشعبية. تتضمن وثائق لغة ترميز النصوص التشعبية 
اګ محتويات للعرض وتعليمات منسَقة تعلم المتصفح عن كيفية عرض 
محتويات الوليقة وروابط الوثائق الأخرى. تطورت لغة ترميز النصوص التشعبية 
1M‏ مع تطور متصفحات الإنترنت لتحقيق عروض مرئية وتوحيد المقايبيس 
بشکل آفضل. 

مبدئياً» عرضت لغة ترميز النصوص التشعبية 1۲١1‏ كلغة لإصدار 
التعليمات للمتصفحات لتحديد ما يتم عرضه للمستخدمين. لكن وحيث إن عدد 
الوثائق المكتوبة بلغة النمذجة الموحدة يزداد» وحيث إن هناك العديد من 
التطبيقات التى بدأت بإنشاء وثائق بلغة ترميز النصوص التشعبيةء أصبحت 
معالجة الحاسوب لهذه الوثائق أمراً فى غاية الأهمية. أما لغة الترميز الموسعة 
XM‏ فقد آنشعت لتوحيد تعريف لغات الترميز المخصصة الأخرى. كما أن لخة 
ترميز النصوص التشعبية الموسعة 11× هي عبارة عن لخة الترميز الموسعة 
1× المتوافقة مع لغة ثرميز النصوص التشعبية 11> التي أصبحت متغيراً 
مسيطراً للخة ترميز التصوص التشعبية. 


حالياًء تعمل مجموعة عمل تقنية تطبيقات الويب ذات النصوص التشعبية 
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(08.ع¥atطw.««#)‏ على تعريف المسار التطوري للغة ترميز النصوص التشعبية 
والتوفيق بين التناقضات بين لغة ترمیز النصوص التشعبية HTML‏ ولغة ترمیز 
النصوص التشعبية الممتدة .×1۲M1‏ هذا وتعمل مجموعات أخرى ك ۷2٥‏ 
على لغة ترميز النصوص التشعبية الممتدة كمعيار. 


بروتوكول نقل النصوص التشعبية :11١۶‏ هو بروتوكول الاتصال 
لشبكة الويب (راجع 2616٣۸۴)»ء‏ وهذا البرتوكول يحدد ثماني عمليات 
أساسية: خيارات 0۴۲10×8» اجلب »G٤1‏ تصدر 8۴45. أرسل ›»P081‏ 
ضع TRACE goتت «DELETE زذİحإ «PUT‏ اربط CONNECT‏ . الأکثر 
استخداماً بين هذه العمليات هما اجلب ٤1‏ وأعلن ۴081. فالعملية G۴١‏ 
تسترجم البيانات المرتيطة بمحدد مواقع المصادر الموحدة 0R]‏ من محدد 
معطى. أما العملية ۲05١‏ فترسل البيانات إلى البرنامج الذي يتلقى محدد مواقع 
المصادر الموحدة المطلوب. 

أثبتت هذه المفاهيم البسيطة أنها فاعلة وقوية وقد كان ذلك مفاجثاً. وجد 
مطورو التطبيقات طرقا مبتكرة لاستخدام محدد مواقع المصادر الموحدة ۸1ل 
لتسمية أشياء متنوعة» ولا يقتصر ذلك على الوثائق. على سبيل المثال» من 
الأفكار التي طرحت مبكراً لاستخدام محدد مواقع المصادر الموحدة U1‏ 
لتسمية برنامج يرغب بتنفيذه على الجهاز الخادم؛ الذي سينتج منه مخرجات 
يتم إعادتها إلى التابع. شبيه ذلك أن الوثائق لا تستخدم لاحتواء المعلومات التي 
سيتم عرضها من خلال متصفح الإنترنت فحسب» بل أنها أيضاً تحتوي على 
مخطوطات الشيفرة البرمجية التي يجب تنفيذها. ثمة منظومة كاملة من اللخات 
التي أنششت لكتابة الشيفرة البرمجية التي يجب تنفيذها من قبل المتصفح (مثال 
ذلك› اpنJava8er)‏ أو على الخادم (مثال ذلك ۶۸۶). تستفید تطبیقات الویب 
من تنوع اللغات وأنماط التصميم لدمج قدرات الخوادم والتوابع. 
7 3 هندسة البرمجيات وتطبيقات الوبب 

أبصرت هندسة البرمجيات النور عام 1968 كرؤية لترويض الصعوبات 
التي اعترضت تطوير البرمجيات في ستينيات القرن العشرين في مشاريع 


تطوير البرمجيات الكبيرة المبكرة. فقد أصبح واضحاً أن البرمجيات الكبيرة 
المتجانسة التي كانت النوع الوحيد من البرمجيات» التي كانت قيد الإنشاءء 


كانت ذات قيود كثيرة. لم يكن ممكناً توسيع تلك البرمجيات في ذلك الوقت 
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لتتجاوز حجماً معيناً» كما لم يكن بالإمكان صيانتهاء وبالتالي كان من النادر 
أن تتوافق هذه البرمجيات مع توقعات العملاء. كانت هندسة البرمجيات 
واعدة بمنهجية نظامية لبناء البرمجيات بناءَ على تصاميم الوحدات ومكونات 
البرمجية المعيارية. أصبحت رؤية هندسة البرمجيات هذه حقيقة واقعة بمرور 
الستين. 

مر تطوير تطبيقات الويب بتاريخ شبيه بهندسة البرمجيات» لكنه سار على 
وتيرة أسرع. فقد تكونت تطبيقات الويب الأولى من العديد من النصوص 
البرمجية المبعثرة في العديد من الملفات» التي افتقدت الهيكلية المنظمة. وقد 
يكون سبب ذلك أن تطبيقات الويب موزعة بطبيعتهاء لكن فكرة المكرّنات 
المفردة التي يمكن جمعها لتكوّن تطبيقات أصبحت حقيقة» وهي أسهل بكثير 
في تطبيقات الويب. تستخدم تطبيقات الويب المكونات المعيارية كوحدات 
الدفع آو التسجيل. في هذا القسم» نتناول العديد من مظاهر تطبيقات الويب 
المرتبطة بقضايا هندسة البرمجيات ارتباطا وثيقا. 


7 1-3 ثابت - دینامیکي - نشط 


ت بناء الويب في مراحله المبكرة بواسطة مجموعة من الوثائق التي كان 
بالإمكان ربطها بحرية مع بعضها البعض. كانت تلك الوثائق عبارة عن ملفات 
نصية بسيطة ذات محتويات ثابتة وروابط ثابتة تربط الصفحات. بمرور الوقت»› 
أدرك التاس أن هذه الوثائق النصية المرسلة من جهاز خادم الويب إلى متصفح 
الويب يمكن أن يتم إنشاؤها بسهولة بواسطة برنامج. وقاد ذلك إلى ظهور 
تطبيقات «راجهة البوابة المشتركة 01©)» حيث يشير محدد المواقع 0۸1 إلى 
نصوص صغيرة أو برامج مترجمة كبيرة يمكن تشغيلها من خلال الخادم لإنشاء 
صفحات ويب ديناميكية. كان برتامج واجهة البوابة المشتركة الذي تم تشغيله 
من خلال الخادم يستخلص البيانات من قاعدة البيانات. أصبح ذلك مرهقاً 
للعديد من التطبيقات لأن وضع جميع محتويات موقع إلكتروني وتهيئتها على 
هيثة شيفرة برمجية لتطبيق ما قد يصبح أمراً مملاً ويصعب إدارته كما يعلم 
مهندسو البرمجيات. أدى هذا الإدراك إلى نموذج هجين توعاً ما» حيث كانت 
لغة البرمجة ۴۲۴ ذات ثأثير مبكر في ذلك. باستخدام ۲۴۶ كانت الهيكلية 
النموذجية تقتضي إنشاء صفحات ويب تتضمن وضع كمية صغيرة من الشيفرة 
البرمجية في نصوص الصفحات مباشرة. في الوقت الذي يرسل فيه طلب» يتم 
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تنفيذ الشيفرة البرمجية وإدخال النتيجية في الوثيقة الحالية. آدى ذلك إلى مرونة 
كبيرة جداً وسهولة في إعادة استخدام مكونات الصفحة؛ لكن وبمرور الوقت» 
آدرك الناس صعوبة إجراء تعديلات على الشيفرة البرمجية عندما كانت متتشرة 
في جميع صفحات الموقع. آدى ذلك إلى إجراء المزيد من التنقيح على 
النموذج لتقارب ما هو شائع اليوم في عالم تطبيقات الويب» حيث إن 
المكونات المركزية في التطبيقات تحكم الوصول إلى البيانات» بينما تكون 
الشيفرة البرمجية الموزعة في صفحات H1١۷]‏ محدودة بما يتم عرضه 
للمستخدمين فقط. 


7- 2-3 تمط تصميم متحكم عرض النموذج 

من وجهة نظر هندسة البرمجيات» تبدو متعلقات العديد من تطبيقات 
الويب متشابهة: فهي جميعها لها واجهة استخدام» ويرتكز استخدامها على 
متصفح الإنترنت وتتفاعل مع المستخدمين وتتحكم بأكبر كمية ممكنة من 
البيانات» ويتم تخزينها في الخادم. استغرق الأمر عدة سنوات قبل أن يدرك 
مطؤرو الويب آن نمط متحكم عرض التموذج «۷٣‏ المعروف في هندسة 
البرمجيات ينطبق كما هو الحال في تطبيقات الويب الممائلة. 


ثم تقديم متحكم عرض النموذج M۷٣‏ لأول مرة في ۸۸۲ ×0× 
عام 1978ء واستخدم للمرة الأولى في تطبيق علهاالة؟ قبل 20 عاماً من 
انتشار استخدام الويب» وقبل 30 سنة من بدء استخدامها في آطر عمل تطوير 
تطبيقات الويب كنمط بنيوي جوهري. إن الهدف من نمط تصميم متحكم 
عرض النموذج حسبما يفيد مخترعوه هو جسر الهوّة بين النمط الذهبي 
للمستخدم والنموذج الرقمي المتواجد في الحاسوب. في الأصل؛ كان 
المتحكم عبارة عن نظام مكوّن من أربع مواد: النموذج (1ءفهM)‏ والعرض 
(View)‏ والمتحكم (Editor) jر~xnÜÛlg (Controller)‏ . توضح متحكم عرض 
النموذج في سياف تطبيقات الويب. النموذج هو عبارة عن مجموعة من الأنواع 
كائنية التوجه»ء تتفاعل مع مستودع البيانات (الذي يكون قاعدة بيانات في 
الأغلب) المتحكم فيتضمن منطق التطبيقات أو العمليات» آما العرض فهو 
مخطوط لتجهيز البيانات من النموذج لإنشاء العرض. يعمل المتحكم على إنشاء 
العروض والاستجابة للاستعلامات التي تنتج من العروض. 
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7- 3 - 3 آطر عمل تطبيقات الويب 


استغرق الأمر عقوداً حتى تصل هندسة البرمجيات إلى أطر عمل تطوير 
تطبیقات یمکن استخدامهاء بحیٹ تدعم هذه الأطر تطویر تطبیقات معقدة بتاءًَ 
على مكونات وتصاميم متشابهة. الفكرة الرئيسة هي توفير هذه المكرّنات في 
إطار عملي قابل للتهيئة والتوسيع. تتوفر الآن منهجيات هندسة الويب القائمة 
على المكونات بوفرة"'* ما يدعم التراكيب كائنية التوجه"» واستكشاف 
الاعتمادية القائمة على المظاهر والسياق» والبحث عن أنماط باستخدام لغة 
النمذجة الموحدة”” . مؤخراء ظهر إطار عملي قوي وسریع في العديد من 
لغات البرمجة التي يرتكز معظمها على نمط تصميم متحكم عرض النموذج. 

حلول وانهR‏ «صه راں‌R‏ : لغة البرمجة Ruby‏ هي لغة برمجة ديناميكية كائنية 
التوجه” أصبحت شائعة لكتابة تطبيقات الويب. وهي تدعم كتابة برامج كاملة 
ومخطوطات يمکن آن تكون جزءأ من ملفات ا11M.‏ ثمة مجتمع نشط 
وديناميكى لهذه اللغة عمل على إنشاء العديد من الحلول الخفيفةء ومن أفضلها 
انه ۸ه وان ۳ » وهو إطار عمل لتطوير تطبيقات الويب بناءً على نمط 
متحکم عرض النموذج. ولهذا الغرض» تعمل لغْة وا۸ على إضافة مجموعة 
من الوظائف الفاعلة كالأساسات والسجل الفعال والترحيل والتوجيه والبيئات 
ومساعدات أخرى عديدة. 


آما الأساسات فهي فكرة عامة في حلول اه۸ ٣ه‏ وط۸ يستطيع المطور 
فيه إنشاء الإصدار الأول من التطبيق باستخدام المخطوطات. تُنشئ الأساسات 
تماذج وعروضا ومتحکمات»› حسما هو مطلوب بتاءَ على مخطط قاعدة بيانات 
معرّف مسبقاً. 

يدعم إطار العمل منهجية التطوير السريعة عند بدء التطبيق بمجموعة 
أساسية من الملقات التي تمنحك العمليات الضرورية للنموذج وتتضمن العرض 
والتحرير واللانشاء والتحديث والحذف. 

ActiveRecord‏ هو مكتبة تتيح للمطور التفاعل مع قاعدة البيانات 
عن طريق إدارة كوائن رطس۴۸ فقط» وهذا يجعل عملية التطوير أسهل حيث 
يعمل المطرر في بيئة yا۸u‏ بشکل کامل من دون استخدام لغة الاستعلام 
المهيكلة ا8Q.‏ 
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الترحيل هر طريقة ية لإإدراة مخطط قاعدة البيانات باستخدام مجموعة من 
الأنواع الخاصة بلغة وان ۸. أما التغيرات التي تطرأً على مخطط قاعدة البيانات 
فى أثناء صيانة البرمجية فتدعمها عملية الترحيل أوتوماتيكياً. يسهل التوجيه 
خرائط الطريق التي يستعلم عنها محدد المواقع URL‏ للمتحكم المرغوب به 
تبسط بيئات العمل المختلفة العمل على نفس الشيفرة البرمجية في مراحل 
مختلفة من مراحل التنفيذ بالتوازي. إضافة إلى ذلك النشر على أجهزة خادم 
مختلفة بقواعد بیانات ونظم تشغيل مختلفة يحدد مرة واحدة» ویتم معالجته 
أتوماتيكياً بواسطة إطار العمل. 

آطر تنفيذ أخرى: تدعم لغات البرمجة الشائعة من قبل أطر تنفيذ تطبيقات 
الويب الخاصة بها. مثلاء 28۴[ هو إطار عمل تطبيقات الويب بلغة الجافا الذي 
بإطار العمل [28٤‏ بوساطة صفحات خادم جافا 8۴ل آما المتحكمات والنماذج 
فهى عبارة عن .Java Servelts yİ Java Beans‏ 

إطار العمل Seaside‏ هو إطار فعال يزيد من قوة ومرونة وبساطة التطبيق 
له٤اله«؟‏ المستخدم لتطوير تطبيقات الويب. أما إطار العمل" فهو مبني على 
لْغة البرمجة «0طار٣‏ . 

أمّا السمة المشتركة لأطر العمل هذه فهي أنها تدعم : 

ب) المطابقة العلائقية الكائنية التي تطابق قواعد البيانات مع الكوائن 

قواعد بيانات صريحة. 


ت) مولدات لإنشاء أجزاء البرامج الفرعية للتطبيق. 


(#) هو إطار عمل تطبيقات ويب حر ومفتوح المصدر مكتوب بلغة البرمجة بايشون. طْوّر أصلاً لإدارة 
مواقع إخبارية تديرها «شركة الما (رممصهآ لاج۷ )٠1٠‏ وأصدر للعموم في تغوز/ وليو 2005 تحت رخصة 
بي إس دي. في حزيران/ ونيو 2008 أعلن عن إنشاء مؤسسة برنامج جانغو التي ستتولى تطوير جانغو في 
المستقبل. هدف جانغو الأساسي تسهيل إنشاء مواقع الويب المعقدة القائمة على فواعد البيانات (المترجم). 
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7- 3 - 4 إصدار تطبيق الويب 

إدارة الإإصدارات هو جزء مجهد ومكلف في هندسة البرمجيات التقليدية. 
آما الوضع فيختلف ديناميكياً بالنسبة إلى تطبيقات الويب. 

ففي تطبيقات سطح المكتب» تتطلب عمليات إضافة المزايا وإصلاح 
العيوب تركيب نسخ جديدة أو تطبيق إصدار فرعي صغير. أثبتت عملية الترقية 
هله أنها صعبة لعدة أسباب : أولاً مشكلة التوزيع البسيطة؛ إذ يجب أن يعرف 
مستخدمو التطبيق آن الترقية متوفرة» ومن ثم عليهم استغراق وقت في التحميل 
والتركيب. ثانياً تكون عملية الترقية في الأغلب عرضة للأخطاء. وبمرور الوقت؛ 
تنزع عمليات تركيب البرمجيات لأن الاختلاف عن «التركيب النظيف»» وهذا 
يؤدي إلى عدد كبير من الحالات التي قد تتعامل معها عملية الترقية. 

تتطلب إصدارات التطبيق ومکتبات قواعد البيانات والمصادر المختلفة 
ترقيات لتصبح أكثر تعقيداً مما قد يكون مطلوباً للانتقال من إصدار إلى الذي 
يليه على سبيل المثال. في حالة الخادم» يتم تبسيط ذلك كله بشكل كبير. يمكن 
إضافة المزايا وتصحيحات العيوب إلى تطبيق قيد العمل حالما تكون جاهزة» 
على تحسين التطبيق بدلا من التعامل مع الصيانة المكلفة والمعقدة ومع قضایا 
الترقية» وهذا يفيد مستخدمي التطبيق لأنهم يحصلون على وصول فوري لآخر 
إصدار من البرمجية. 

وبناء على ذلك» فإن تطوير التطبيقات مفتوح أكثر لأساليب التطوير 
السريعة لأنه حتى الوحدات الوظيفية الصغيرة قد يتم توفيرها للمستخدمين فوراً 
بدلا من توفيرها ضمن حزمة من الوظائف الأخرى التي تكون عرضة للجدولة 
التعسفية ما يعني عدم توفرها للاستخدام فورياً. مقارنة بتطبيقات سطح المكتب 
التي يكون لها دورات إصدار مدتها عدة شهور أو عدة سنوات»ء لا يكون الأمر 
مستغرباً إذا تم تحديث تطبيقات الويب عدة مرات في اليوم الواحد. 


7 - 4 التوجهات الحالية 


يمكننا تعريف قوتين على الأقل تؤئران في التوجهات الحالية في تطوير 
تطبيقات الويب. فمن ناحية» ثمة وظيفة جديدة تحكم تطوير أنواع تطبيقات 
ويب جديدة» ومن ناحية أخری» هناك منهجيات هندسية جديدة بتاء تطبيقات 
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التطبيقات. في هذا القسمء نراجع ما يأتي: 
آ) ظاهرة مشاركة المستخدم كمثال على الوظائف التي تؤثر في تطوير 
تطبيقات الويب. 


ب) مفهوم من سطح المكتب إلى الويب» كمفهوم يؤدي إلى إعادة هيكلة 
تطبيقات الويب. 


7- 4 - 1 توجه التطبيق : المشاركة 


ما زال البعض يعرضون تطبيقات الويب للمعنيين على أنها «وسيلة 
للتوصيل المحتوى»"”. ففي حين آن توفير محتوى هو أحد استخدامات 
تطبيقات الويب» إلا آن هناك جيلاً جديداً من تطبيقات الويب التي تضمَن 
المستخدمين في تلك التطبيقات عن طريق عرض مزيد من التفاعل والتواصل 
والمشاركة بين المستخدمين» وتدرج المستخدم لإيجاد قيمة في التطبيق. تبيّن 
الدراسات الحديثة“" أن مواقع الإنترنت تعتبر "مواقع جيدة٠‏ حسب التوجهات 
في الأعوام الأخيرةء ذلك آنها تور للمستخدمين تفاعلاً أكبر من المحتوى. 
يشار إلى ظاهرة تطويع المستخدم في تطور تطبيقات الويب على أنها «مشاركة 
المستخدم». يشير أوريلي Rely)‏ 0 إلى أن المشاركة هي إحدى آهم 
المتحكمات في الويب 20. نعرض في هذا القسم بعض أنواع تطبيقات الويب 
التي تشتق قوتها وفعاليتها من مشاركة المستخدمين. 

أنظمة التدوين (و«عاور؟ عه81): حسب الويكيبيدياء المدونة هي موقم 
إنشرنت تتخذ المدخلات فيه الأسلوب الصحفي وتعرض بترتيب زمني عكسي. 
إن قدرة القراء على إضافة تعليقات بطريقة تفاعلية تتيح للآخرين رؤيتها والتعليق 
عليها هي خاصية آساسية في مواقع التدوين. ظهرت المدوؤنات أول ما ظهرت 
في نظام Blogger.com‏ . المدونة هي موقم على الاإنترنت يديره أحد 
المستخدمين »› حیث يقوم بإضافة المحتوى عن طريق الإرسال!ا. یتم رتيب هله 
الإرساليات في فثات» ويمكن التعليق عليها من قبل مستخدمين آخرين. إن 
الحركة في المدونات كثيفة» حيث يربط المدونون مدوّنات أخرى في 
إرسالياتهم. وبذا فإن المدوّنات ذات كثافة روابط كبيرة جداً. هناك ما يزيد على 
0 مليون مدونة على شبكة الإنترنت في وقتنا هذا. 
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ثمة مفهوم ذو صلة وثيقة بالتدوين والمدؤنات آلا وهو ملقمات البيانات 
الديناميكية. ظهر مؤخراً مخطط التوحيد البدائي ل ۸88“ وأصبحت متداولة بين 
المستخدمين وهو يتطلب وجود مواقع للتصويت على الإنترنت لتحديث محتويات 
اM×.‏ تستخدم العديد من المدونات ۸58 لإشعار القراء بالتغيرات التي تجرى 
على المدونة. تعمل تطبيقات التجميع على دمج ملقمات ۸88 مختلفة لإنشاء 
مواقع بمحتويات أغنى. المدونات هي مثال واضح على ظاهرة غيّرت من نموذج 
نقل الأخبار. تعرض المدونات نموذجاً مختلفاً عن الصحف المطبوعة التقليدية. 
فهي توفر نموذجاً جديداً للمجتمع للوصول إلى معلومات محدثة ومتجددة عمّا 
يجري في العالم» وإن يكن ذلك من دون عمليات التحرير الصحفي. 

نظم الويكي (وصعاورS :)W[)İ‏ تشبه نظم الويكي كموقع عia.0۲لءماkاw‏ 
المدوّنات ظاهرياً لأنها ترتكز على مشاركة المستخدمين فى إضافة المحتويات. 
هذه المكونات الأساسية هي عبارة عن صفحات كما في مواقع الإنترنت 
التقليدية» مقارنة بالمدؤنات التي تكو فيها المكونات الأساسية عبارة عن 
إرساليات (التي يمكن عرضها مع بعضها البعض ضمن الصفحات تفسها). تتيح 
مواقع الويكي للمستخدمين قراءة وتعديل محتويات الصفحات. إن الافتراض 
الأساسي هو أن مواقع الويكي تعرض معرفة الآراء عبر الزمن (أآو على الأقل 
الآراء) لجميع المستخدمين. وكما هو الحال في المدونات» تعرض الريكي 
كثافة روابط عالية. إضافة إلى ذلك تتوفر فيي الويكي روابط كثيرة بين 
الصفحات لأنها توفر بناء بسيطاً لربط المستخدم بالصفحات» سواء تلك 
الموجودة أو التي سيتم إنشاؤها لاحقاً. كما توفر معظم مواقع الويكي المصادقة 
وترقيم الإصدارات لتقييد عمليات التحرير التي قد يقوم بها المستخدمون وذلك 
ليكونوا قادرين على استعادة عمليات التحرير القديمة. 

نظم و ضع العلاماث الثشار كية (8عصءاور؟ ع٣‏ iععa :)۳C1aborative‏ نشیر 
إلى وضع العلامات على أنها قدرة المستخدم على ربط المصطلحات (علامة) 
على صفحة ويب أو مصدر ويب. يمكن أن تُستخدم هذه العلامات لاحقاً 
للعثور على المصادر بدلا من تسمية المصادر. هذا ويمكن أن تستخدم العلامات 


Really Simple Syndication (&)‏ صيغة بيانات لنشر التلقيمات وهي وسيلة لتمعكين البرمجيات والنظم 
المختلفة من استهلاك ما تنشره نظم غيرها من حتوى» ومن تطبيقانا تقكين القراء من متابعة آخر أخبار المواقع 
من دون الحاجة إلى زيارة كل موقع على حدة (المترجم). 
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أيضاً لتصنيف المصادر. تتبع التطبيقات الحديثة التي تنظم المعلومات نموذجاً 
جديداً يدعى وضع العلامات التشاركية» حيث يعتمد مبدأه على افتراض بسيط 
هو أن المستخدمين يعرفون كيفية وصف مصادر الريب بمصطلحاتهم الخاصة 
وأنهم يغطون جوانب من المصادر بالتشارك أكثر من الخبراء أو الفهرسة 
الأوتوماتيكية. على سبيل المثال» يعتبر الموقع m٥icker.cاF‏ أحد تطبیقات 
0 ويستخدم لتخزين الصور ومشاركتها وتنظيمها باستخدام المصطلحات. 
کما آن وں.هعا.اە٥‏ هو تطبیق آخر من تطبیقات 0٥طه۲‏ التي تشير إلى صفحات 
الويب من خلال اكتشاف المستخدمين عندما يستعرضون الصفحات ويخصصون 
المصطلحات لصفحات الويب. ومن تطبيقات وضع العلامات التشاركية على 
صفحات الريب صتء.رص0ده0وطن8 وصتء. نالات اللذين يتظمان الإإصدارات 
العلمية ويتشاركان بهما مع المستخدمين. ما الموقع gq RealTravel.com‏ نظام 
تدوين منظم باستخدام العلامات التشاركية. 


الدراسة الميدانية التى أجريت حول بيانات العلامات التشارك 7137“ 
كشفت السلوك التشاركي للمستخدمين. أما الدراسات الاستقرائية*" فتناقش 
نظام العلامات التشاركية على أنه نسخ تشاركية من ملاحظات ومشاهدات 
المستخدمين على أساس المصطلحات. أما عالم الهندسة الأكاديمية وهندسة 
الويب فهو يدرس الآن هذا النموذج في العديد من التطبيقات حتى تلك التي 
تعمل من خلال سطح المكتب. 


الحوسبة البشرية («i0اةا»مصم٣‏ موس ): تمكن دراسة نظم الحوسبة 
البشرية في المرجع" بناء على مبدأً أن بعض المهام المعقدة يمكن أن تتاثر 
ببساطة بالبشر» وهذا أمر صعب بالنسبة إلى الآلات. من الأمثلة الجيدة على 
ذÛكd «Completely Automated Public Turing Test t(oرlصتخ-| gag CAPTCHA‏ 
Tell Computers and Humans Aparb>‏ أي #اختبار تورنغ العام والمژتمت للتمييز 
بين الحاسوب والانسان» أو التأكيد المنظور". 


(8) الكابتشا هو ا-ختبار يستطيع من خلاله الحاسوب وضع أسئلته» وتصحيح إجاباهاء ولكنه لا بستطيع حل 
هذه الأسئلة» حيث لا يستطيع حلها سوى عقل بشري قادر على التمييز» وبالتاي تكون أي إجابة صحيحة على آي 
من أسئلة هذا الاختبارء هي إجابة لمستخدم إنسان وليست برنامج حاسوب. وتستخدم اختيارات الكابتشا في كثير 
من التطبيقات منها على سبيل المشال» الاستمارات اللناصة بإنشاء بريد إلكتروني في المواقع التي تقدم تلك الخدمةء 
وذلك لمنع التطبيقات الحاسوبية المبرتجة من إنشاء صناديق بريدية -خاصة بها بشكل آوتوماتيكي مثكرر وبأعداد هائلةء 
ثم استخدام هذه الصناديق في ما بعد لإرسال رسائل دعائية وغير مرغوب فيها لباقي المستخدمين (المترجم). 
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فالاسم يتحدث عن نفسه» ويمكنك مصادفتها في العديد من مواقع 
الإنترنت. بشكل أساسي» تكمن الفكرة في تشويه النص على صور ملونة 
والطلب من العميل الإعلام عمَّا كان ذلك النص. إذا كان العميل إنساناًء فإنه 
سيتمكن من قراءته ببساطة؛ أما إذا كان العميل حاسوباًء فإنه لن يتمكن من 
ذلك خلال فترة زمنية قصيرة. يميّز هذا الاختبار بين الإنسان والآلة. ومن 
الاستخدامات الأخرى مقايسة الصور التى جعلت عملية وضع علامات تشاركية 
جماعية (يقوم غوغل بذلك في لعبة ۴5۶۴)» وبشكل عام هي مثال على الحوسبة 
البشرية للفهرسة» استناداً إلى ملاحظات بسيطة مضمونها المصطلحات. 


7- 4 - 2 الانتقال من سطح المكتب إلى الويب 


من التوجهات النامية في تطبيقات الويب الحديثة انتقال الوظائف التي 
كانت تنفذ دائماً في السابق كتطبيق تقليدي من خلال سطح المكتب لتعمل من 
خلال متصفح الإنترنت. من أمثلة ذلك تطبيقات معالجة النصوص ومعالجة 
الجداول والتقاويم والبريد الإلكتروني ومعالجات المعلومات الشخصية؛ فقد 
انتقلت هذه التطبيقات الأساسية للمستخدمين مؤخراً لتعمل على هيئة نماذج 
على الإنترنت. وهذا يعني أن الوظائف التي كانت تنفذ سابقاً من خلال سطح 
وهي متاحة للمستخدمين من خلال متصفح الإنترنت. وهذا يتضمن أن التطبيق 
وبیاناته يكون مركزياً وتعرض كخدمة للمستخدم. 

إن سهولة التشارك هي إحدى الفوائد الرئيسة لنقل آي تطبيق من سطح 
المكتب إلى الويب. فعن طريق نقل البيانات إلى موقع مركزي يمكن الوصول 
إليه من عدة أطراف» تمتاز تطبيقات الإنترنث بتوفير منصات تشاركية أسهل. 

لا يمكن عرض الوثائق وتحريرها من قبل العديدين من دون الحاجة إلى 
إدارة التحويل بين الإإصدارات الأمختلفة فحسب» بل إن التشارك ذا الزمن 
الحقيقي من خلال الإنترنت هو خطوة كبيرة في تسهيل التواصل والتفاعل الذي 
يتم عبر المسافات المتباعدة. 

تحقق المركزية العديد من المزايا (إضافة إلى بعض المساوئ). فإدارة 
البيانات بطريقة أوتوماتيكية والنسخ الإحتياطية هي ميزة قياسية يمكن آن يوفرها 
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عن طريق الاحتفاظ بالبيانات في خادم» يمکن وضع مخطط للنسخ 
الاحتياطي ليخدم آلاف المستخدمين في الوقت نفسهء وذلك خلافاً للحالة التي 
يقوم فيها کل مستخدم بإدارة تسه الاحتياطية الخاصة عند تخزین البيانات 
محليا, هذا ا ١‏ يتطلب جر ضوابط للوصولية لخادم البيانات وو جود 
صخر ن اتود اھ م فی حا دد کی می جوی المستخدمين التي 


إذأء ما الذي يعيق انتقال كل التطبيقات إلى الإنترنت؟ يمكن تقسيم هذه 
القضايا إلى قسمين أساسيين: التفاعل واستخدام الموارد. إن الكمون الذي 
يحصل عن طریق تردد جميع التفاعلات ذهاباً وإیاباً ب بين المتصفح والخادم يعني 
أن العديد من تطبيقات الويب لا تكون متجاوبة بقدر نظيراتها من تطبيقات سطح 
المكتب. إن سرعة الضوء التي توفرها موجهات الإنترنت لا يمكن التغلب عايها 
بسهولة من قبل المواقع التقليديةء لكن الخدمات الكبيرة المستندة إلى الويب 
كغوغل تطبق حلول نظم موزعة معيارية للمشكلات عن طريق تكرار خوادم 
التطبيقات في أرجاء العالم كافة. عندما يزيد عرض نطاق الاتصال المثالي وتقل 
فترة الكمون» عن طريق الانتقال إلى روابط الألياف على سبيل المثالء فإن 
ذلك سيحد من وقع المشكلة للجميع» لكنه لن يخدم معظم التطبيقات ذات 
البيانات الكثيفة. في بعض الأحوال» سيساعد الانتقال إلى نموذج نظير - نظير 
في تحسين فترة الكمون؛ كما ذكر في القسم 2-5-7ء لكن ذلك مشكلة أساسية 
يتكبدها آي نوع من نظم المعالجة الموزعة. آما المصدر الأكبر للأداء الضعيف 
من حيث التفاعل فهو حقيقة أن منطق تطبيق الويب يمكن أن يكون منْفذاً بلغة 
برمجة ذات مستوى متقدم فقط ک امpناeھھبو[.‏ على الرغم من أن ذلك أحد 
العوامل اليوم كما هو الحال في معظم قضايا المواردء إلا أنه ليس من المرجح 
أن تستمر هذه المشكلة» بشكلها الحالي على الأقل. 

طالما أن تطبيقات لغات البرمجة في تحسن مستمر وسرعة المعالجات في 
زيادة مطردةء فإنه لن تكون مشكلة في المستقبل القريب للجميع؛ » نها ستؤثر 
في التطبيقات ذات المعالجة المركزة. في الوقت الراهن» حتى أن أجهزة 
الهواتف الخلوية تحتوي على معالجات فاعلة جداً. الذاكرة ووسائط التخزين 


هى قيود إضافية على الموارد تجعل من بعض التطبيقات مقيدة بسطح المكتب؛ 
لكن كما هو الحال في طاقة المعالجة» زادت السعات التخزينية بمعدل جيد 
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بحيث يمكن الآن أن توفر الشركات الكبرى لعملائها سعات تخزينية مجانية 


عالية تقدر بوحدات عديدة من جيغابايت (وعارطاهع6). 


لا شك أن هناك مزايا ومساوئ لهذا التوجه؛ لكن حيث إن جودة الاتصال 
بالإنترنت وتقنيات الويب في تحسّن» فإن المساوئ الأساسية لقترة الكمون 
والتفاعل ستخضع غالباً لهذه التطورات التي توفرها النماذج التي تعمل من 
خلال الإنترنت. 


7- 4 - 3 من صفحات الويب إلى خدمات الويب 


من التوجهات الأخرى التي تخيّر طريقة بناء تطبيقات الوبب هو نشوء 
خدمات الويب. خدمة الويب هی جڙزء من الوظائف التى يمکن الوصول إليها 
من خلال الإنترنت بواجهة استخدام معيارية. يتم تشفير صيغة الرسالة ب 1× 
ويتم استدعاء الخدمات بنمط اتصال إجرائي عن بعد .)۸۲٣(‏ يتم عرض 
الخدمة ككائن يوفر بَيِيات للوصول إلى العمليات عن بعد. تعرض العديد من 
مواقع الإنترنت الآن خدمات التطبيقات الخاصة بها للمستخدمين إضافة إلى 
خدمات الويب» بحيث يمكن للبرامج (آي تطبيقات ويب أخرى) الوصول إلى 
الخدمات أوتوماتيكياً. خدمات الويب تجعل أمر بناء تطبيقات الريب ممكناًء 
وذلك بدمج خدمات من مواقم مختلفة عديدة. على سبيل المثال» تسهيلات 
البحث التي يقدمها موقع ماعەە وقاعدة بيانات الكتب التي يقدمها موقع 
«معوصه يمكن الوصول إليها من خلال خدمات الويب» وهكذا فإتها تعرض 
کمکونات أو خصائص أساسية للتطبيقات. 

يبشر استخدام خدمات الويب لبتاء تطبيقات الويب في تحقيق العديد من 
أهداف هندسة البرمجيات العديدة كتكييف المكؤنات وإعادة استخدامها. في 
سياق تطبيقات الويب إن تكييف المكرّنات مبدا فعال بلا شك ذلك أن 
المكزنات يمكن أن توفر خدمات تتراوح من المركزية العالية إلى التعميم. مثلاء 
خدمة البحث التي تقدمها Google‏ هي عامة لكن خدمة الخرائط تتيح الوصولية 
إلى بيانات كان جمعها مكلفاً حيث تطلب الأمر استخدام الأقمار الصناعية»› 
وهذا غير متاح لكل مطوري الويب. 

إن المواقع ذات كثافة البيانات العالية ك ماعمهت وموقع تشارك الصور 
نا۴ وغيرهما توفر لمطوري الريب 4۴١١‏ تتيح الوصول إلى البيانات والصور 
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عن بعد. وهذا يتيح للأطراف الخارجية إنشاء تطبيقات جديدة بالاستفادة من هذه 
البيانات وتعطي مرونة كبيرة للمستخدمين نظراً إلى سهولة الوصول إلى البيانات من 
آي مكان في العالم باستخدام متصفح واتصال بالإنترنت. 


4-7 - 4 سطح المكتب الدلالي الاجتماعي 


ظهرت قضايا تصميم الويب في تطبيقات سطح المكتب أيضاًء وذلك 
بظهور نظم برمجية جديدة برمجت باستخدام تقنيات الويب تعمل من خلال 
سطح المكتب» كوسائل لتمثيل وتواصل وتنظيم المعلومات. هذا هو الحال في 
سطح المكتب الدلالي الاجتماعي حیث یعتبر داەسهص تنفیذا زي 52۵ , 
سطح المكتب الدلالي الاجتماعي هو امتداد لنظم التشغيل التقليدية › التي تهدف 
إلى إعطاء سطح المكتب أصبغة نظم الملفات الدلالية وبنية تحتية تشاركية 
لتطبيقات عديدة تعمل من خلال سطح المكتب للتواصل معها. مثل هذه البنية 
التحتية أمر مرغوب به لدعم التطبيقات الجديدة ودعم الشبكات الاجتماعية 
والأعمال المعرفية وإدارة واستكشاف المجتمعات ومشاركة الملفات واستكشاف 
المعلومات وصياغة المعرفة والتصور. 
7 5 التوجهات المستقبلية 

تتوسع شبكة الويب بسرعة في العديد من النواحي. ولا يستشنى من ذلك 
تطوير تطبيقات الويب. من الممكن أن التقنيات الثورية ستعمل جنباً إلى جنب 


لتغيير النماذج الحالية. هذه الأمور لا يمكن توقعها. فبالنظر إلى التوجهات 
الحالية وخرائط الطريق التقنية الموضوعة لمطؤري التطبيقات الأساسية» من 


الممكن توقع بعض التطويرات التي يمكن إجراؤها في المستقبل القريب. 

يمكتنا تصنيف المجالات التي ستؤثر فيها عمليات تطوير قطبيقات الويب 
إلى أربعة مجالات : دعم العملاء (مثال» المتصفح) ودعم البنية التحتية (مثال» 
الشبكة) ومتطلبات التطبيق (مثال» الشبكات الاجتماعية) والمنهجيات التصميمية 
(مثالء طبقات التطبيق). 


7- 5 - 1 قضايا التصفح 
لغات البرمجة المستخدمة لبتاء تطبيقات الويب تعمل على ترميز الحكمة 
التراكمية للمجتمع في ما يتعلق بأفضل الطرق لبناء هذه التطبيقات. بمرور 
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الوقت تؤثر توجهات التطبيقات والمزايا فى الأجيال الجديدة من لغات البرمجة 
الئى تسيل عمليات تطوير المزيد من المزايا المتقدمة. أما لغات البرمجة القديمة 
PERL‏ وPH۴‏ أو حتی اpنا‏ 8ل فقد كانت تهدف أساسا إلى دعم 
المتصفح أو الخادم. أما لغات البرمجة الحديثة ك راه فهي ذات أغراض عامة 
وتغطي مجال المتصفح كاملا ومنطقية التطبيق ووظائف الخادم. 

مؤخراًء أصبحت لغات البرمجية الديناميكية غير المطبوعة (كلغة واس۸) 
أكثر شيوعاً في مجال تطوير الويب؛ وحيث إن سرعات المُعالج تزيد وأصبحت 
تنفيذات اللغة أكثر تطوراًء لا شك أن هذا التوجه مستمر. هذه اللغات حررت 
المطؤرين من التعامل مع تفاصيل معيّنة في الآلة ونظم التشغيل بحيث أصبحت 
منطقية التطبيقات تركز على التطوير. في هذا السياقء من الأهمية بمكان أن 
نذكر تطوير اصا#٥48 N‏ وهو معيار لبرمجة صفحات الويب التفاعلية التي 
تتطور باستمرار لتصبح لغات برمجة ديناميكية كاملة يمكن استخدامها لتطوير 
البرمجيات كما في تطبيقات سطح المكتب المعقدة التقليدية. يمكن النظر إلى 
ECMAScript J Jı qi gle JavaScript‏ . 


إن لغة البرمجة أو اللغات التي تمكن الجيل القادم من تطبيقات الويب 
مهمة» لكن ما يرازيها أهمية هر البيثة التي تشعْل فيها هذه اللغات» ألا وهى 
متصفح الإنترنت. فما كان في يوم من الأيام مترجماً لملفات النصوص البسيطة 
التي تتضمن بعض العلامات آصبح اليوم محرك مترجم متطور منصة تطبيقات. 
أصبحت متصفحات الإنترنت البيئة التشغيلية الأساسية لمعظم تطبيقات الحوسبة 
على نحو واسع عن غير قصد» ويبدو أن ذلك هر بداية التحول في النموذج في 
تشر البرمجية. الانتقال إلى المرحلة الثانية سيتطلب جهوداً حثيثة. 

بما إن المتصفح هو ما يوفر جميع الإمكانيات لمطرر تطبيقات الويب؛ 
فهو ما سيستمر في كونه محور التركيز في معظم التطوير في مجتمع الويب. من 
المرجح أن الوظائف طويلة المدى المضمنة في بيئة المتصفح ستحكمها 
التطبيقات الأكثر شيوعاً التي تعمل في الجيل القادم من تطبيقات الويب 
الديناميكيةء لكن هناك عدداً من التطويرات التي تلوح في الأفق القريب. 

لعدد من الأسباب»ء بما فى ذلك الأمنء أعطيت متصفحات الويب وصولية 
محدودة للمصادر المحلية المتواجدة في جهاز الحاسوب الخاص بالمستخدمين. 
تكمن الفكرة في أن الوظيفة الأساسية للتطبيق تكون موجودة في الخادم» وهنا 
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يوفر المتصفح واجهة استخدام رسومية بسيطة (001) للمستخدمين للوصول إلى 
الوظائف المتواجدة في الخادم. 

إن عدم القدرة على الاستفادة من المصادر المحلية هو عائق مام العديد 
من تطبيقات الويب. الكعكات (وعiمهه٣)‏ هى الالية الوحيدة المستخدمة لتخزين 
المعلومات ضمن بيئة المتصفح المعياري» هي شكل محدود جداً من أشكال 
تخزين القيم الأساسية. بالبدء بالوظائف الإضافية طهها۴» ومن ثم تطبيقها في 
متصفح الإنترنت» في النسخ الأحدث من المتصفحات» فقد عززت الكعكات 
لتكون بمثابة نموذج تخزين يبعرض في مجموعة عمل تقنية تطبيقات النصوص 
المتشعبة الخاصة بالويب ۷۸4۲۷6 . في هذا النموذج»ء يمكن أن تخزن 
التطبيقات بيانات مهيكلة بواجهة ذات قيمة أساسية» لكن وبخلاف الكعكات» 
لا ترسل البيانات إلى الخادم في كل عملية طلب لإحدى صفحات الإنترنت. 
في نموذج التخزين الجديد» تكون بيانات الدورة آو البيانات الشاملة متواجدة 
دائماً محلياً مع المتصفح» بحيث تتمكن النصوص البرمجية التي تشغل ضمن 
الحواسيب التابعة من الوصول إلى هذه البيانات بشكل صريح. ويتوقع أن يسهل 
هذا العديد من الصعوبات البالغة في تطبيقات الويب» کما ستتیح لعدد من 
نماذج التطبيقات الجديدة بالظهور. 


من المظاهر الأخرى لتقنيات المتصفح التي ستستمر في تحسين قدرات 
تطبيقات الويب هي النظم الفرعية الرسومية التي أصبحت الآن جزءاً من العديد من 
المتصفحات. إن علامة ۷aةدجء‏ التي قدمتها شركة eاApp‏ أول مرة في متصفح 
8ء هي الآن معيار من معايير مجموعة عمل تقنية تطبيقات النصوص 
المتشعبة الخاصة بالریب ۷۸۸1۷8 التی ضمّنت أيضاً فی ×و]إع مم 
وةإ#م0. إن عنصر النصوص التشعبية على مستوى الوحدة توفْر لجانب 
المستخدم إمكانية البرمجة بسياق الرسم ذي البعدين المرتكز على المتجهات 
مشابه للحواشي التذييلية أو نتموذج آلم. إن بيئة الرسومات المضمنة في 
المتصفح تمنح تطبیقات الويب مرونة عالية في إنشاء المحتويات التي کانت في 
ما سبق مقتصرة على الخادم فقط. على سبيل المثال» الرسوم البيانية 
والمخططات الرسومية في معالجات الجداول يمكن أن يتم إنشاؤها الآن فى بيئة 
المتصفح لتحقيق تفاعل كبير وعرضها خارج الشبكة ما يعني إمكانية تعديلها. 
هله 8ء هي بداية انتقال ما کان يعرف بمکتبات البيانات على مستوى النظام 


إلى بيئة المتصقح» وليس من سبب لتوقع أن يتوقف هذا التوجه إلى هذا الحد. 
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ثمة تحسينان واضحان إضافيان هما البيثة الرسومية ثلاثية الأبعاد ومعالج 
الأحداث المرتكز على ة۷صهء. ويتضمن ذلك دعم بيئة ترجمة الأبعاد الثلالية 
المتسارع من حيث الأجهزةء الذي يلمح في كل من مواصفات مجموعة عمل 
تقنية تطبيقات النصوص المتشعبة الخاصة بالريب #۸41۷6 وخريطة الطريق 
الخاصة ب ×۴0٥ء۴1‏ سيفتح الشبكة لأول مرة لتصبح بيئة ثلائية الأبعاد حقيقية 
حالی تنتج Îدšl canvas‏ عنصراً مکافتاً لصورة على الصفحةء لكن وجود معالج 
الأحداث الخفيفة يتيح إنشاء محتوى أكثر ديناميكية كعناصر الواجهة المخصصة 
والألعاب التفاعلية. 


7- 5 - 2 البنية التحتية للشبكات 


إذا استمر توجه الانتقال من سطح المكتب إلى الويب» سيكون هناك عقبة 
أخرى كبرى تتمثل في الحاجة إلى الاتصال الدائم بالإنترنت أو قدرة التطبيق على 
التعامل مع الاتصال المتقطع بالخادم. بهدف علونة هذه القضية»ء تم توحيد 
مجموعة عمل تقنية تطبيقات النصوص المتشعبة الخاصة بالويب ۷141۷6 فى 
مجموعة من الأحداث التي يمكن أن تُعلم التطبيقات قيد العمل عن حالة الشبكة. 
وهذا یتیح لأمعالجات الجداولء على سبيل المثال» تخزين معظم البيانات الحديثة 
محلياً بحيث يتم استعادتها حالما يتم الاتصالء وهنا لن يتم فقدان أي من 
البيانات. إضافة إلى ذلك» عن طريق إعلان التطبيق أنه خارج الاتصال» يمكن 
تخزين منطق البيانات والتطبيق محلياً بحيث تستمر بعض جوانب تطبيق الويب من 
دون الاتصال بالشيكة. في هذا النموذج› يصبح الويب آلية نشر للتطبيق وتصبح 
المتصفحات بيئة تنفيذية › بدلا من أن تون مجرد تطبيق لتصفح الياتات. 


إن زيادة استخدام ملقمات ۸88 سار يداً بيد مع النمو السريع لمنتجات 
الوسائط غير المركزية على شبكة الإنترنت. فكما رأيتا سابقاًء أنشأت المدوتات 
نموذجاً جديداً لنشر الأخبار. لكن الطريقة الحالية التي تقضي بإرسال البيانات 
أولاً إلى موقع الإنترنت» ومن ثم يتم استقصاء رأي المستخدمين حول تحديث 
البيانات» لهي الطريقة المجدية الوحيدة لنشر محتوى إلى عدد كبير من الناس. 
لْعَنوّنة مشكلات التدرجية لطريقة نشر البيانات هذه يجب استثمار أسلوب نشر 
الملفات نظير - نظير. ومن آشهر بروتوکولات النشر نظیر - نظیر 8i)۲۵ ٣٣۵٣٤‏ 
الذي يمكن استخدامه لهذا الغرض. يتيح هذا البروتوكول لأي عدد من العملاء 
تنزيل أجزاء من المحتوى في الوقت ذاته عن طريق إنشاء شجرة مشاركة كبيرة 
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غير متبلورة. يعمل کل من متصفحي ۲4ء0 PFirefoxg‏ على دمج بروتوکول 
التنزيل نظير - نظير بحيث يمكن التزيل مباشرة من خلال المتصفح بشكل 
متواصل. ما هذه إلا البداية لتکامل نظیر - نظیر (۴2۴) في المتصفح. في 
المتصفحات المستقبلية أو مساعدات المتصفح» من المرجح دمج آنواع أخرى 
عديدة من خدمات ۲2۲. ستنتقل البيانات التي كانت تنشر في خادم ويب 
مركزي وحيد إلى شبكات ۶2۶ موزعة تتيح سرعة الوصول إلى البيانات» إضافة 
إلى قابلية عالية غير محدودة. 

تتطلب تطبيقات الويب أيضاً إضافة إلى الوصولية السريعة لبيانات 
الويب» كمية كبيرة من السعة التخزينية. أحد الأمثلة على ذلك الخدمة الحديثة 
التي تتصرف كمثال على مصدر بيانات من طرف خارجي خدمة التخزين 
البسيطة التي تقدمها 20ص۸ آو 3. في هذه الخدمة» توفر أمازون شبكتها 
التخزينية العالمية لمطوّري الويب کاداة ذات آغراض عامة مع الاحتياجات 
التخرينية القابلة للقياس. يمكن تخزين البيانات واستعادتها من خدمة 83 بقضل 
واجهة خدمات الويب البسيطة التي يمكن الوصول إليها من خلال تطبيق خادم 


أو المتصفح. 


يجب أن توفر تطبيقات الويب موئوقية وأداء ومتطابات الجودة شآنها شآن 
ألويب بطريقة ممنهجة. لكن ثمة مشكلات تتعلق بتطوير الويب تحدث عنها 
جينايج #عن«ا وتشاير إنهط عام 1999" التصفح والوصولية والموثوقية؛ 
ولا تزال هذه المشكلات واقعاً. إن استخدام أطر العمل الخاصة بالويب كتلك 
التي عرضنا لها في الأقسام السابقة يساعد (كنموذج لإعادة استخدام المكونات) 
على عنونة معظم هذه القضايا ويژدي إلى تحسين مطرد في تطوير تطبيقات 
الويب. في هذا القسم»› عرضنا منهجیتين تبحثان عن طرق جديدة لتصميم 
تطبيقات الويب. 

مواصفات الخدمات (وع :)Specification o۴ Servic‏ تعرض شبكة الويب 
حالياً طيفاً كبيراً من الخدمات التي جمعتها تطبيقات الويب لعرض المزيد من 
الخدمات الشاملة والمفيدة للمستخدمين. إن المنهجية التركيبية لخدمات الويب 
قد خدمت مچتمع خدمات الويب جیدا. لكن يتفاعل عدد كبير من الخدمات 
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والتطبيقات بالعديد من الطريق غير الواضحة للعيان. إن فهم التفاعلات الشاملة 
والعمليات وهيكليات البيانات في نظم الويب أمر صعب من وجهة نظر 
خارجية» وسبب ذلك غالباًء أن المطرّر لا يملك وصولية للشيفرة البرمجيةء أو 
بسبب أن الشيفرة البرمجية كبيرة جداً بحيث يستغرق المرء وقتاً طويلاً لفهم 
فكرة الوظائف التى تؤديها. نحن نرى حاجة إلى مواصفات دقيقة لتطبيقات 
الويب وخدمات الويب كمهمة مهمة. إن تحديد نظم الويب يمكن أن يساعد 
كجسر بين المتطلبات والتطبيق وكمرجع لفهم النظام. لقد اختبرنا باستخدام 
المواصفات المنطقية المؤقتة*"“ في حالة وضع علامات المشاركة. إن الحصول 
على مواصفة من صفحة واحدة كوسيلة تواصل مع النظام كاملا يجعل من 
السهل التفاعل مع المطورين والمعنيين في مشاركة الفهم نفسه عن النظام. 

الويب الدلالي (طاء۷ ءناد«ء5) : معظم البيانات الحالية المتاحة على شبكة 
الويب تكون ملفات معزولة تربط في ما بينها بعض الروابط أحياناً. تنشأً هذه 
الوثائق في المقام الأول لتعالج من قبل المستخدمين. آما هدف الويب الدلالي 
فهو إثراء هذه البيانات بحيث يمكن معالجتها أيضاً بواسطة برامج الحاسوب. 
الفكرة هنا هي زيادة البيانات المتاحة مع بعض المعلومات الإضافية (بيانات 
وصفية) لتصف ماهية البيانات وسببها. يُنظر إلى هذه البيانات الإضافية على أنها 
توفير «دلالات» للبيانات. من الواضح آنه إذا كانت هذه المعلومات التي يمكن 
الوصول إليها آلياً متوفرة» تصبح إمكانية توفير جيل جديد كامل من تطبيقات 
الويب متاحة. يمكن أن تتبادل التطبيقات البيانات ودلالاتهاء وبذا تجتب الكثير 
من قضايا التوافقية. 

أساسيات الويب الدلالي (8لة† :)Semantie Web Fundam‏ في قسم 
آساسيات الويب» عرفنا محددات مواقع المصادر الموحدة 0۸1 على أنه جوهر 
التفاعلات في الويب كنظام» كما عرفنا لغة الويب على أنها M1‏ #۲. أما 
جوهر الويب الدلالي فهر معرّف المصادر الموحد R۸1‏ وهر نموذج معمم 
لمحددات مواقع المصادر الموحدة أما لغته فهي لخة إطار عمل وصف 
المصادر 0۴ ۸. آما لغة الويب الدلالي فهي لغة التفاعل التي تدعم التطبيقات 
المهمة التي تزيد يوما بعد يوم» والتي توفر تفاعلا في محتواها بين التطبيقات 
والمستخدمين. أما رؤية الويب الدلالي فهي دعم مثل هذا التفاعل كالية آساسية. 


إن محاولات تقديم ملخصات دلالية أخرى مضمنة في وثائق ۸۲1 
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كالصیغ الجزئية" أو لغة إطار عمل وصف المصادر ۸0۴ تبدو حلولاً مؤقتة 
جيدة. من ناحية أخرى» بدو شبكيات المعلومات" مثالا جيداً على طريقة 


رؤية الهندسة للويب الدلالي (Engineering Vision of the Semantic Web)‏ : 
قمنا بوصف نمط تصميم متحكم عرض النموذج في القسم 2-3-7. حالياًء 
تستخدم العديد من أطر عمل تطبيقات الويب هذا النمط بنجاح. لقد استغرق 
تحول هذا النمط إلى معيار في تطبيقات الويب وقتا طويلا وتطلب إجراء العديد 
من التجارب. ماذا عن حالة الویب؟ ماذا لو صممتا الويب كاملا حسب نمط 
التصميم هذا؟ ما من شك أن ذلك سيحل العديد من مشكلات التصميم 
كالتوافقية والتناغم وسهولة الوصول» وغير ذلك. الويب الدلالي مصمم بنمط 
تصميم متحكم عرض النموذج. النموذج معقد تماماً لكته متوحد في طريقة 
تقديمه. يمكن اعتبار النموذج على أنه لغة إطار عمل وصف المصادر ۸2۴ 
أمعرّف المصادر الموحد 0۸1 والمتحكمات هى تطبيقات ويب» أما ما يمشله 
فهو صفحات 1۲× التاتجة» وذلك بخلاف الوضع الحالي لمجموعة نمافج 
الويب كاملة في قواعد البيانات ونظم قواعد البيانات المختلفة وصيغ الملفات 
وغيرها. سنكون قادرين على الوصول المباشر إلى آي نموذج يقع على بعد 
وذلك من أي تطبيق (بتوفر تمشيل كائنية التوجه)ء بغض النظر عن قضايا 
الشبكات وتحولات البيانات والهيكلية والصيغ المختلفة. لا شك أن هذا عرض 
ملخص متقدم وسيتم تطبيقه بعد عدة سنوات. لكن كرؤية» يمكن أن يقود 
عملية إنشاء تطبيقات ذات هيكلية جيدة وجديدة. 

تطبيقات الويب الدلالي (nsهاaء‌ناممA Web‏ ieاموصم8):‏ لبناء تطبيقات 
الويب الدلالى ذات الهيكلية المحددة جيداً بصورة روتينيةء من الضرورة بمكان 
توفر أطر عمل لتطبيقات الويب الدلالية ذات التصميم الجيد التي توفر بنية 
تحتية للويب الدلالي. أحد الأمثلة على هذه البنية التحتية خادم التطبيقات للويب 
الدلالي ×۸0 . حالياًء تظهر تطبيقات الويب الدلالي بالصورة البدائية 
كتوسع لتطبيقات موجودة حالياً كالمدونات الدلالية والويكي الدلالي <۶ 
والمخازن الدلالية وسجلات العناوين الدلالية. 


من دراسات الحالة لتطبيقات الويب الدلالية تلك الخاصة بالتراث 
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الثقافي ۶ التي توفر القدرة على التصفح والروابط والوصف الكامل لمعالم 
العالم الفنية. 
7 6 الملخص والاستنتاجات 

في هذا الفصلء قمنا بمراجعة التوجهات الحالية والمستقبلية في تطوير 
تطبيقات الويب. ألقينا نظرة على مشاركة المستخدمين كمتحكم أساسي في 
التطبيقات مستقبلا. لقد اخثبرنا تطوير تطبيقات لويب من وجهة ظر نة 
البرمجيات. وقمنا بتقييم تطوير البئية التحتية التي تقو إعادة هيكلة تطبيقات 
الويب. بعض التوجهات واضحة: تنتقل بعض ابات ذات كثافة البيانات 
الكبيرة من سطح المكتب إلى الويب. تتكون التطبيقات من خدمات موزعة 
بشكل واسع؛ تدعم التطبيقات التعاون والتفاعل بين المُستخدمين على نحو 
متزايد. من الصعوبة بمكان التوقع بما هو آت. لا شك آن البنية التحتية 
لشبكة الويب ذات التصميم الجيد ضرورية وأن الويب الدلالي هو طريقة 
طموحة لتحقيق ذلك. على آقل تقدير» لاب من توفر آنماط تصميم جديدة 
لتطوير تطبيقات الويب؛ حيث يجب أن توفر هذه الأنماط مستوى متقدماً من 
التفاعل بين المستخدمين. يجب أن تكون عملية تطوير تطبيقات الويب 
سريعة» كما يجب أن تستمر عمليات التطوير وأطر العمل لتحقيق هذا 
المتطلب. 

تمت عمليات تطوير تطبيقات الويب بسرعة لالتقاط دروس فى هندسة 
البرمجيات» وهي الآن تقود العطبيق بأساليب السرعة لبناء نظم برمجية جديدة 
وموزعة بطريقة متطورة. 
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الج الثالت 


تقنيات تطؤر البرمجيات 


8 
الترحيل إلى خدمات الويب 


(Harry M. Sneed) kw ۴ هاري‎ 


1-8 القوى التي تقود عملية الترحيل 

من حيث المبدأ» يقف مستخدمو تكنولوجيا المعلومات موقفاً ثابتاً من 
حالة الترحيل. فمن الصعوبة أن ينجحوا في الانتقال إلى بيئة تقنية جديدة قبل 
أن تصبح تلك البيثة بائدة» وقبل أن يواجَهوا بضرورة الانتقال مرة أخرى. ثمة 
قوتان تقودان عملية الترحيل : 

© القوة الأولى تَغْيّر تقنية المعلومات بثبات. 

# القوة الأخرى تغْيّر عالم الأعمال بشبات. 

هناك بالطبع علاقة معقدة بين القضيتين» ما يجعل أمر التعامل معهما كل 
على حدة آمراً صعباًء لكن هذا الفصل ضروري لفهم ترابطهما . 

1-1-8 تغير التكنولوجيا 

تتغير تقنية المعلومات بمعدل مرة كل خمس سنوات. فى سبعينيات 
وثمانینیات القرن الماضي› کال معدل التغيير مرة کل عشر سنوات. إن سیب 
هذا التقصير في دورة حياة التقنية ليس تزويد المُستخدمين بوظائف أكثر 
فحسب» بل لتلبية احتياجات سوق رآس المال آيضاً. يرزح مزوؤدو تقنيات 
البرمجيات تحت ضغط کبیر من المساهمين لزيادة مبيعاتهم ولرفع آرباح 
الشركات. لغاية الآن» الطريقة الوحيدة لحمل ذلك هي تقديم منتجات جديدة 
وإقناع المستخدمين بشرائي^" . 
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نشر مزڙدو البرمجيات ثقافة آن کل شيء جديد جميل٬‏ وآن کل شيء 
قديم بشع» مدعومين بنزوات التقنية من العالم الأكاديمي. حتى يحظى المزود 
باحترام أقرانه ومستخدمي تكنولوجيا المعلومات الآخرين» يجب آن يكون رائداً 
من رواد التكنولوجيا. أما أولئك الذين يتمسكون بالتكنولوجيا القديمة فيعامَّلون 
بازدراء. وهذا ينطبق على الأفراد والشركات على حد سواء. فكلاهما يجري 
التلاعب بهما من قبل عمليات التسويق التي يقوم بها المزودون والحاجة إلى 
مواكبة نظرائهم. إن حقيقة أن التكنولوجيا الجديدة تحسن من آدائهم لهو موضع 
تساۋل. ثمة شكوك تساور نيکولاس كار اه٣‏ هاطعا وغيره من الخبراء فى 
مجال الأعمال بهذا الشان“. ٠‏ 


الحقيقة هي أن مستخدمي تكنولوجيا المعلومات يشعرون بأنهم مجبرون 
على الانتقال إلى تكنولوجيا جديدة حتى من دون وجود دليل على آنها 
ستخفض من التكاليف وتزيد من الإنتاجية» بل إنها تدفع إلى مصير مجهول 
وهم يثقون ثقة عمياء أنهم على الطريق الصحيح. ليس من مستخدم لتكنولوجيا 
المعلومات يرغب في البقاء بعيداً عن القطع خوفاً من البقاء معزولاً أو خوفاً من 
أن يعتبر غريباً. يبدو أنهم يتقبلون حقيقة أن الترحيل أمر لا مغر منه. 


بزيادة تعمد تعمد التكتنولوجيا الجيدة» فإن فوائد استخدامها زادت بشكل واضح. 
أصبحت مزايا التكنولوجيا الجديدة التي تفوق بها مزايا التكنولوجيا القديمة أقل 
وضوحاً من ذي قبل» لذا يتوجب على المزودين إنفاق المزيد من الأموال في 
السوق لإقناع المستخدمين أن التغيير جيد لهم. أصبحت فكرة العائد على 
الاستثمار قضية أساسية في تقديم التكنولوجيات الجديدةء لكن غالباً ما يتم 
التلاعب لصالح التكنولوجيا الجديدة“ . 


في بدايات الحوسبةء كانت التغيرات في الأجهزة والمعدات هي ما يقود 
عمليات الترحيل. كانت البرمجيات ولغات البرمجة أقل أو أكثر اعتمادا على 
الأجهزة التى كانت تعمل عليها. كانت تكاليف البرمجيات أقل مقارنة بتكاليف 
آخری. فقد کان یمکن تشغیل برامج فورتران )۴٣٣۳۵۳(‏ وکوبول (00801) في 
حزمة واحدة وكان يمكن معالجة البطاقات المثقبة والأشرطة المغنطيسية 
ووحدات الأقراص القابلة للإزالة. أما حديشاًء فقد أصبحت التغيرات 
التكنولوجية أكثر من مجرد قضية برمجية؛ فلغات البرمجة والوسائط هي ما 
يحكم الترحيل الآن. 
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بدا هذا التحول في 1990 بالانتقال إلى نظم التابع - الخادم. هتاء شمل 
التغيير كلا من الأجهزة والبرمجيات. رغبت كل إدارة في الشركات بالحصول 
على حاسوب محلي خاص بها ذي محطات عمل طرفية؛ لكن لا يزال 
الحاسوب المحلي بحاجة إلى أن يكون متصلاً بحاسوب مركز مستضيف في 
مكان ما بقاعدة بيانات شاملة. إن الاتصال بالعديد من نقاط الاتصال فى بيئة 
التابع - الخادم أصبح مشكلة كبرى ويؤدي إلى الاستعانة بالوسطاء. في هذه 
البيئة موزعة الأجهزة» آصبح من الضروري توزیع البرمجيات أيضاً وهذا 
جعل من ادر تحويل نموذج البرمجة من نموذج إجرائي إلى نموذج ذي 
توجه کائني G1‏ 


كانت تكاليف الانتقال إلى نظم تابع - خادم الأساسية عبارة عن تكاليف 
البرمجيات فقط. آما البرامج المركزية الحالية فكان لاب من تحويلها أو إعادة 
كتابتها. فقد كان لزاماً تقليص حجم العديد منها لتناسب السعات التخزينية 
للخرادم المحلية ,. 


يتطوي الانتقال من التظم المركزية إلى نظم التابع - الخادم على العديد من 
التقنيات المعقدة كإلغاء واجهات الاستخدام والتحول من الهيكلة الهرمية إلى 
قواعد البيانات العلائقية وتقليص حجم البرامج وتحوّل الإجراءات إلى اللغات 
كائئية التوجه” . كان لابد من اتخاذ الكثير من التنازلات لدفع عملية الترحيل 
في وقت مقبول بتكاليف مقبولة. غالبا ما يتم حجب برمجيات جيدة بهدف تلبية 
متطابات بيئات الأجهزة الموزعة الجديدة. بذلت جهود عظيمة لتجسيم التظم» 
أي تحويل البرامج الإجرائية إلى مكونات كائنية التوجه. كانٽ تلك مهمة صعبة 
للغاية» ولم يتم حلها بشكل مُرض البتةء على الرغم من حقيقة أن العديد من 
الأبحاث اختصت بي , 


معظم المستخدمين كانوا عبارة عن محتوی في النهاية لاإعادة تطبيق 
واجهات الاستخدام الخاصة بهم ولتحويل بياناتهم إلى قواعد بيانات علائقية. 
نجح القليل من المستخدمين في إعادة تطوير تطبيقاتهم القديمة بطريقة كائنية 
التوجه. وسبب ذلك أنهم لم کور ا على إعادة التقاط كيف كانت النظم 
القديمة تعمل بالتفصيل. أما إعا ة توثيق النظم القديمة إلى مستوى العملية 
الأساسية ومن ثم إعادة تنفيذها پک مختلفة فكانت تكاليفها باهظة جداً. بذاء 
بالانتقال إلى تكنولوجيا التابع - الخادم» فإن جودة البرمجيات الحالية في 
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تطبيقات الأعمال تحولت فعلياً كنتيجة لعدم التطابق هيكل5 . 


إلى هيكلية التابح - الخادم» حتى ظهرت الموجة القادمة على هيئة اللإنترنت. 
أبطل هذا الترحيل العديد من مظاهر ترحيل نظام التابع - الخادم. الآن» كان من 
ا ل ا مشترك بحیث يعمکن 
بقیت كافنية التوجه› ا لابڌ ا رر إلى العمليات ا 
من الخارج. أدى ذلك إلى تدمير الغرض من التسلسل الهرمي للنوع. إضافة إلى 
ذلك كان لابد من استبدال واجهات الاستخدام التي نفذت باستخدام آدوات 
واجهات الاستخدام الرسومية 601 بصفحات الويب المنفذة بلخة ا۸۲M1.‏ بل 
أكثر من ذلك» كان لاب من جميع البيانات الموزعة مرة أخرى في قاعدة 
بيانات مشتركة عامة ذات قابلية للوصول. 


كان على معظم مستخدمي تكنولوجيا المعلومات إكمال الانتقال من نظم 
التابع - الخادم إلى شبكة الإنترنت عندما أصبحت التكنولوجيا الأحدث متوفرةء 
تحديداً الهيكلية خدمية التوجه. الآن» أصبح من الضروري تقسيم البرمجية إلى 
مكّنات خدمية مخزنة في خوادم شبكة ذات واجهة خدمة ويب معيارية. يجب 
آن تستبدل النظم التابعة بإجراءات عمليات الأعمال المبرمجة بلغة تنفيذ عمليات 
الأعمال ا8۲۴ التي تقود العملية وتعرض البيانات وتقبلها من خلال صفحات 
الأنماط المتسلسلةء وتنفذ خدمات الويب. الآنء كل عملية من العمليات 
المحلية يجب أن تحافظ على حالتها وعلى بياناتهاء بما إن خدمات الويب 
يجب أن تكون بلا حالة وبلا وصولية بالنسبة إلى مستخدمي قاعدة البيانات. 
تتطلب الهيكلية خدمية التوجه انفصالاً جذرياً عن التقنيات السابقة وإعادة تجديد 
تطبيقات الأعمال . 


الهيكلية خدمية التوجه هي ثالث تغير كبير في نموذج التكنولوجيا في 
الخمس عشرة سنة الأّخيرة» التغيرات المدفوعة بحاجة صناعة البرمجيات إلى 
تحقيق مكاسب جديدة. إن مستخدمي تكنولوجيا المعلومات ما هم إلا ضحايا 
لصتاعة تكنولوجيا المعلومات سريعة التقلب» التي تسعى من خلال استخدامها 
إلى الحفاظ على الإيرادات بتقديم تقنيات جديدة باستمرار. إذا تاب مستخدم ما 
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تغيرات التقنيات» فلاب آن يكون في حالة ترحيل مستمرة من تقنية إلى آخرى. 
في الحقيقة › إن الترحيل بين التقنيات حالة دائمة في معظم الشركات الكبرى» 
التي أسست وحدات تنظيمية لهذا الغرض فحسب» إضافة إلى مراكز البرمجيات 
العديدة بما فيها المراكز الجديدة في الهند التي تزدهر بفضل هذه الترحيلات 
اة ^ . 


2-1-8 تغير الأعمال 


إضافة إلى الضخط الذي تسببه تغيرات التكنولوجياء ثمة قوى أخرى تقود 
تغير الأعمالء تحولت الشركات من البنى الهيكلية الكلاسيكية العميقة التى 
شاعت في عقد السبعيئيات» إلى وحدات الأعمال الموزعة التي ظهرت في عقد 
التسعينيات ومنها إلى التنظيميات ذات التوجه القائم على العمليات والشبكات 
والقائمة على الحوسبة بشكل كامل. إن التغيرات التي تطرآ على الأعمال اليوم 
مقترنة بالتغيرات التي تطرآ على تكنولوجيا المعلومات. من دون الإنترنت» لن 
کون من الممكن أن دير الشركات عملياتها ذات المراكز الموزعة في مناطق 
عديدة في العالم» كاستحالة تقسيم الأعمال إلى وحدات أعمال مفردة من دون 
ربطها مع بعضها البعض من خلال أجهزة خوادم قواعد بيانات مشتركة في 
هيكلية الخادم - التابع. في هذا الصددء تكمّل التغيرات الي تجرى على 
الأعمال وعلى التكنولوجيا بعضها البعض الآ . 

التخيرات في الأعمال تقودها الرغبة في إدارة الأعمال بكفاءة من حيث 
التكاليف. إن ثورة إعادة تصميم الأعمال التي قادها هامر ۲ة ونشامبي 
رصسهط تهدف إلى هيكلة الأعمال تبعاً لعمليات الأعمال". فبدلاً من تقسيم 
مسؤولية عملية معيّنة بين العديد من الوحدات المختلفة تختص كل منها 
باختصاصات معيَّنة» كانت وحدة واحدة فقط مسؤولة عن العملية كلها منذ 
بدايتها إلى نهايتها. هذا موه ضح أفضل ما يكون في مثال التعامل مع المسافرين 
في رحلات الطيران. سابقاً كان ثمة موظف واحد يعمل في الخارج للتحقق 
من المسافرينء وموظف آخر في الداخل لاصطحاب المسافرين إلى الطائرة. أما 
اليوم› فهناك موظف واحد يتحقق من المسافرين ويصطحبهم إلى الطائرة. هذا 
الموظف مسؤول عن عملية تحميل الطائرة بالكامل. أما العملية الموازية التي 
تتعلتق بآمتعة المسافرين» فتكون من مسؤولية موظفين آخرين 

إن تخصيص مسؤولية عمليات الأعمال لوحدة واحدة أو شخص واحد من 
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شأنها آن تسهل ضمان مساءلة المسؤولين وقياس الأداء. من الواضح آن وحدة 
الأعمال المسؤولة عن العمليات المحلية لا ترغب فى الاعتماد على دائرة 
تكنولوجيا المعلومات العامة لإنجاز عملها. فالمدير المسؤول يرغب في أن 
تكون لديه وحدة معلوماتية محلية خاصة به ويشرف عليها. إن هيكلية النظم 
الموزعة توفر هذا الحل. في التهاية» يكون لكل وحدة أعمال جهاز خادم محلي 
وفريق عمل مختص بتكنولوجيا المعلومات يقدر على العمل حسب الطلب. 
على الرغم من آن إنتاجية وحدات الأعمال المقردة زادت» فقد زاد إجمالي 
تكاليف الملكية أيضاً, أما تكاليف صيانة الحلول المختلفة لكل نشاط فقد 
أصبحت أكبر من تكاليف المشاركة في المواره*؟ . 


يعد مقهوم تکنولوجیا المعلومات خدمية التوجه بمعالچة هله المشكلة. 
فهي محاولة لتو حید مفهوم وحدات الأعمال الموزعة المستقلةء التي تعالج کل 
ي يمكن تطبيقها في عمليات عديدة. إن الهيكلية خدمية التوجه (804) في 
حقيقتها قضية أعمال أكثر مما هي قضية تكنولوجية. يتطلب عالم الأعمال اليوم 
ومكلفة. حتى لو كانت تتبع المنهجية السريعة فإنها ستتطلب وقتا لتسويق منتج 
قابل للعملء كما إن نتيجتها لا تكون مؤكدة. تتطلب البرمجيات المفيدة وقتا 
لتنضج»؛ وهذا وقت لا تملكه معظم وحدات الأعمال المتنافسة. ثمة حاجة ملخة 
لمفهوم «برمجيات عند الطلب». وهذا يعني أن الوظائف الأساسية يجب آن 
تكون متوفرة قبل أن يكون هناك طلب عليها. كل ما على مستخدمي الأعمال 
عمله هو الاختيار من قائمة كبيرة من الخدمات البرمجية (الوصف العام 
والاكتشاف والتكامل 0221) أي تلك الوظائف التي تتطلبها لعمليات الأعمال 
الخاصة بها ولتجهيز إجراءات التحكم لاستدعاء الخدمات الجاهزة والارتباط بها 
باستخدام لخة عمليات الأعمال* . 


8 2 ظهور خدمات الوبب 


ا شرکات تکنولو جي المعلومات من إجراء برجي ي إلى وسيم 
عند ا إليها (أي توفر المكرنات البرمجية المكونة للخدمة البرمجية). وهذا 
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يعني إعداد مستودع للمكرنات البرمجية التي يمكن إعادة استخدامهاء الرؤية 
الدائمة لعالم البرمجيات التي بدآت بمكتبات لغة الفورتران في ستينيات القرن 
الماضى»ء وتطورت إلى وظائف ۶1/١‏ المدمجة ومكتبات الماكرو فى عقد 
السبعينيات» التي استمرت مع وحدات الأعمال التي يمكن إعادة استخدامها في 
عقد الثمانينيات ثم تراكمت في مكتبات الأنواع (9ه1١)‏ في التسعينيات. 

لقد كان هدف صناعة البرمجيات دائماً إعادة استخدام أكثر ما يمكن من 
مكرناتها المؤكدة. إن تأثر ذلك في تكاليف التطوير أقل من تكاليف الاختبار. 
يتطلب الأمر جهوداً هائلة لاكتشاف جميع عيوب البرمجية وإصلاحها ولشرح أن 
البرمجية تؤدي الوظائف التي يُفترض آن توديها. لأجل ذلك» بتوجب أن تمر 
البرمجية عبر عملية نضج طويلة. سيكون من غير المعقول أن لا ترغب في 
إعادة استخدام ما ثبت جدواه بالفعل. في هذا الصددء خدمات الويب هي سبب 
آخر لاعادة استخدامها بشکل متكرر . 

أما الأمر المختلف في خدمات الويب فهو أنه يمكن أن توجد فيزيائياً في 
آي موقع في شبكة الإنترنت العالمية حتى أن لها واجهة استخدام ذات وصولية 
معيارية» وأن تطبيقها مستقل عن البيئة التي تشعّْل فيها. سابقاًء المكرّنات التي 
يمكن إعادة استخدامها كالأنواع المتوفرة في مكتبة الأنواع المشتركة كان لاب 
أن تكون متوافقة مع الأنواع التي تستخدمها أو تتوارثها. وهذا ينطبق أيضاً على 
وحدات الأعمال القياسية. لم تعد تلك هي الوضع بوجود خدمات الويب؛ إذ 
يمكن تطبيقها بأي لغة حتى لغة التجميع البدائيةء وبأي نظام تشغيل طالما آنها 
قادرة على خدمة واجهة الاستخدام خاصتها. 

إن استخدام واجهة الاستخدام القائمة على الرسائل مع ×٧1‏ وبروتوكول 
وصولية الكائن البسيطة 504۴ تجعل من تطبيق برمجيات الخدمات مستقلة عن 
الأجهزة التابعة. إن لغة تعريف خدمة الويب ا۷82 هي لغة قائمة على 1× 
لتفسير الرسائل التي تمرر بين الخدمة والتوابع. يجب أن تكون برمجية الخدمة 
قادرة على قراءة وكتابة رسائل لغة تعريف خدمة الويب. يمكن أن تتواجد 
خدمات الويب في آي نقطة في الشبكة وهذا ممكن بواسطة آليات ق 
۴, كل خدمة لها عنوان فريد خاص» ويمكن أن تستلم رسائل من 
نقطة في الشبكة لها قدرة على الوصول إلى ذلك العنوان° . 


ليس هناك من فروق حقيقية بين خدمات الويب والروتينيات الفرعية 


235 


القياسية التى استخدمت فى عقد الستينيات» عدا الميزات الخاصة بالإنترنت 
التي ذکرناها مسبقاً. . فهي تعالج مجموعة من الطلبات التي تستخدمها لينتج من 
ذلك عدد من نتائج المعالجة. فإذا كانت عديمة الحالةء فإنه لن يكون لها ذاكرة 
خاصة بهاء وهذا يعني أن البيانات الوسيطة التي تجمعها ستفقد حالما تنتهي. 
وهذا يعني عبقاً إضافياً من حيث صيانة حالة المعالجة الصحيحة في الجهاز 
التابع. أما إذا احتفظ بحالة البيانات فإنها تصبح أكثر تعقيداً لأنه في هذه الحالة 
يجب أن يتم التمييز بين التوابع والسشاظ َ على بياناتها منفصلة. وهذه أيضا 
مشكلة متكررة الحدوث» فقد وجدت في أجهزة مراقبة المعالجة عن بعد في 
عقد الثمانيتيات» مثال ذلك ٥10٥S‏ و٣1M8-2‏ وقد حلت تلك المشكلة بعدة 
طرق مختلف ة0 , 


آما مشكلة خدمات الويب فهي المشكلة تفسها التى واجهتها الوحدات 
القياسية القابلة لإعادة الاستخدام. وهذا هو السؤال الذي يطرح نفسه على 
التفاصيل. كم هو عدد الوظائف التي يجب آن توفرها خدمات الويب؟ على 
سبيل المثال» يمكن أن تكون خدمات الريب خاصة بمعالجة الحسابات البنكية» 
ويتضمن ذلك جميع الوظائف کفتح حساب والإيداع وسحب المال وتحويل 
الأموال وحساب الفوائد وإنشاء كشف حساب والتحقق من حدود الائتمان 
وإغلاق الحساب. وهذا سيتطلب بالطبع واجهة استخدام عالية التعقيد. ومن 
ناحية أخرى» قد تكون خدمات الويب مقتصرة على حساب الفائدة فحسب. 
وهذا يؤدي إلى الحاجة إلى واجهة استخدام أكثر بساطة . 

سيفضل مستخدمو الأعمال الحل الثاني - تفاصيل أصغر - لأنه يوفر لهم 
مرونة عالية. ستفضل إدارة تكنولوجيا المعلومات تقديم الحل الأول لأن إدارثه 
تكون أسهل. إن وجود العديد من الرسائل سيضع حملا كبيراً على الشبكة 
ذلك أنه يجب آن تمر هذه الرسائل ذهاباً وإياباً بين التوابع والخوادم على 
الويب. لم تكن تلك هي الحالة عندما استخدمت الروتينات الفرعية القياسية أو 


الأنواع الأساسية التي تعمل في العنوان تفسه الذي يعمل فيه مستخدموها. وهذا 
يولد مشكلتين بحاجة إلى الحل: 

® مشكلة الحفاظ على الحالة. 

® مشكلة تحديد التفاصيل. 

يتوجب على الباحثين التعامل مع هاتين القضيتين والتوصل إلى حلول قابلة 
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للتطبيق حتى تتمكن خدمات الويب من التكييف. لا يتوجب الحفاظ على الحالة 
فحسب» بل يجب أن يتم ضمان تلك الحالة. آما المستوى الملائم من التفاصيل 
فيعتمد على السياق» ويجب أن يتم تحديده لكل وضع على حدة. ليس من حل 
شامل» فلن يكون من السهل العثور على حلول ملائمة لهذه المشكلات. 

هناك مشكلة ثالثة تتمشل في كيفية العثور على خدمات ويب في المقام 
الأول. لن يتم العشور عليها بغمضة عين بطبيعة الحال» بل يجب شراؤها أو 
استتجارها آو استعارتها أو استعادتها أو بناۋها. وهذه هي البدائل الخمسة لتوفير 
خدمات الويب التى ستناقش هنا. 
8 - 3 توفير خدمات الويب 

مصادر خدمات الويب الخمس هى (كما ذكرت سابقاً) : 

آن يتم شراؤها. 

۵ آن يتم استنجارها. 

۵ أن يتم استعارتها. 

8 أن يتم بناۋها. 

آت يتم استرجاعها. 

8 1-3 شراء خدماث الويب 

یمکن شراء خدمات الویب من مزود برمجیات. فمعظم تجار حزم برمجيات 
المجال لأي مستخدم تكنولوجيا المعلومات في شرائها. وهذا ينطبق على 
برمجيات الأعمال التجارية والبرمجيات العلمية والهندسية التى يمكن شراؤها 
جاهزة للاستخدام. من فوائد خدمات الويب الجاهزة للاستخدام ما يأتي : 

® متوفرة بسهولة ویسر. 

۵ تکون مختبرة جيداً وموثوقة نسبياً. 

8 تكون مدعومة من قبل البائم. 

يجب أن لا يستهان بالفائدتين الثانية والشالثة. إذ يتطلب الأمر بذل جهود 
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كبيرة لاختبار الخدمات حتى لو كانت خدمات ويب بسيطة ذات استخدامات 
متباينة. كما آنه من المريح معرفة أن خدمة الويب لن تتطلب صيانة بشكل دوري»› 
ولن تحتاج إلى تعديل» وبذا لن يقلق المستخدم بشأن التعامل مع هذه الأمور. 

أما مساویء خدمات الويب الجاهزة للاستخدام فهي کما يأتي : 

8 تكون غالية الثمن في الأغلب. 

۵ یکون استخدامها مقتصراً على وظائفها. 

# لا يكون لدى المستخدم إمكانية لتعديلها. 

# غالبا ما تكون كبيرة الحجم ومتراصة. 

آما أكبر مساؤى هذه الخدمات الجاهزة فهي آنها ليست مرنة بما فيه 
الكفاية. إن استخدام خدمات الويب كبيرة الحجم والمُتراصة كنظم الفوترة 
الجاهزة للاستخدام أو برمجيات التحقق من الائتمان هو كالبتاء باستخدام 
الجدران الجاهزة. یتو جب على مستخدم تکنولو جیا المعلومات بناء عملیات 
الأعمال خاصته باستخدام خدمات الويب المشتراة. على هذا النحوء تحدد 
خدمات الويب كيفية بناء عمليات الأعمال المرتبطة بها. وهنا فإن المُستخدم لا 
يشتري البرمجية فحسب» بل عمليات الأعمال كلها أيضاً, 


بالنسبة إلى بعض مستخدمي تكتولوجيا المعلومات» قد يكون ذلك نعمة. 
فهم لن ينفقوا الوقت والجهد في تصميم عمليات أعمالهم» لكنهم سيخسرون 
أهم ميزة من مزايا خدمات الويب الرئيسة ألا وهي المرونة. كما قد يشترون 
عملية الأعمال كاملة» كما كان الحال فى السابق. لا يوجد أي معثى في 
الانعقال إلى الهيكيلية خدمية التوجه. أما بالنسبة إلى مستخدمى تكنولوجيا 
المعلومات المتحمسين لتخصيص عمليات الأعمالء فهذا تقييد لا يُطاق. ما 
الذي سيدخل إطار المنافسة إذا كان كل منافس يستخدم عملية الأعمال نفسها؟ 


8 3 - 2 استتجار خدمات الويب 


طريقة بديلة عن شراء خدمات الويب هى استئجارها. العديد من بائعى 
البرمجيات الجاهزة كنظم 84۲ وعاعة0 يعملون الآن على تنفيذ خطط لتصبح 
خدماتهم متاحة على أساس التأجير. فبدلاً من الاضطرار إلى شراء الحزم 
البرمجية وتنصيبها في أجهزتهم الخاصةء يكون لدى مستخدم تكنولوجيا 
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المعلومات خيار استخدام الوظائف التي يتطلبها فقط عندما يتطلبها (آي على 
الطلب). ومن ثم يدفع مقابل الاستخدام الفعلي فقط. لمشروع الأعمال هذا عدة 
فوائد تفوق أسلوب الشراء: 

© يعمل المستخدم دائماً بآخر إصدار محدّث. 

© يدفع المستخدم مقابل ما يستخدمه فعاياً فقط. 

إن امتلاك البرمجية لا يكون ذا منفعة للمستخدم دائماً؛ إذ يجب أن يتحمل 
ويختبرها في بيئة عمله إضافة إلى تنصيب واختبار الإصدارات الجديدة منها. إن 
صيانة البرمجية في بيثة المستخدم ذات تكلفة عالية. أما الفائدة فهي أن 
المستخدم يستطيع تعديل البرمجية لتتواءم مع متطلباته الخاصة. لا يكون 
المستخدم ملزماً بتعديل عملية الأعمال خاصته لتلائم البرمجية المعياريةء وهي 

ينطبق الأمر ذاته على خدمات الويب. فإذا كان المستخدم يشتري هذه 
الخدمات» فإنه يمكن آن يكيّفها. أما إذا كان يستأجرهاء فعليه أن يستخدمها 
كما هي. إذا كانت تفاصيل خدمات صغيرة بما فيه الكفاية» لن تكون هناك 
مشكلة كبيرة بالنسبة إلى المستخدم؛ إذ يمكنه بناء هذه الخدمات في عمليات 
الأعمال خاصته كبناء حجارة الحصى في الجدار الإسمنتي» لكن إذا كانت هذه 
الخدمات مبنية كآلواح من الإسمنت الجاهز» فيجب على المستخدم تكييف 
الإصدارات الجديدة بشكل دائم واختبارها . 

8 - 3 - 3 استعارة خدمات الويب 

إن أخذ خدمات الويب من مصدر مفتوح مكافى لاستعارتها. إن مناصري 
التطبيقات مفتوحة المصدر هم أولئك الذين يفضلون أن يَدَعوا الآخرين ينفذون 
يرغبون أن يدفعوا مقابل هذا العمل» ومن ناحية أخرى»ء هم لا يرغبون في 
تطويرها. تعتبر خدمات الويب مفتوحة المصدر ملكية عامة يمكن لأي كان 
استخدامها. 
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هتاك آمران هناء الأول أدبى والآخر قانونى. الأمر الأدبى هو أن البرمجية 
هي ملكية فكرية بما في ذلك خدمات الويب. فقد قام أحدهم بالتضحية بوقته 
الثمين لإيجاد حل لمشكلة معضاة. فإذا كان هذا الحل ذا قيمة بالنسبة إلى 
شخص آخر» فإنه يجب أن يكون مستعداً لدفع ثمنه. وبخلاف ذلك» فإنه يخرق 
مبادئ اقتصاد السوق الحرة. لذا وفي هذا الصدد»ء إن استخدام خدمات الويب 
ذات المصدر المفتوح موضع شك ولا تنسجم مع المجتمع الذي نعيش فيه. 

أما الأمر القانوني» فهو المسؤولية. من الذي يكون مسؤولاً عَمَّا تنفذه 
الخدمة المستعارة؟ طبعأًء لا يمكن أن يكون مؤلفو الخدمة هم المسؤولون› 
وذلك لأنهم غافلون عن مكان وكيفية استخدام ملكيتهم الفكرية. وبناءٌ على 
ذلك» يكون المستخدم الوحيد للملكية الفكرية هو مستخدم البضاعة المستعارة. 
عند أخذ خدمات الويب من مصادر مفتوحة» يكون للمستخدم حرية تكييف 
المصدر مع احتياجاته الخاصةء لكن يجب أن يفترض أيضاً آنه مسؤول عن 
تصحيحه وجودتهء أي آن يقوم باختباره تماماً لجميع الاستخدامات الممكنة. 
معظم الأشخاص لا يدركون أن اختبار البرمجية مكافئ من حيث الوقت 
والتكلفة لتطويرها. وإذا كان المصدر غير مألوف للأشخاص الذي يجب أن 
يكيقوه ويصخحوه» فقد يكون أغلى مما لو قاموا بتطوير تلك البرمجية بأنفسهم. 
بهذه الطريقة» ستكون الشيفرة البرمجية على الأقل مألوفة أكثر لهم. آثبت العديد 
من الدراسات أن صيانة البرمجيات هو التأثير الذي يقضون في محاولة 
فهو , 

إن فهم الشيفرة البرمجية هو الحاجز الأكبر الذي يعترض استخدام الشيفرة 
البرمجية للمصادر المفتوحة. لذا فإن المستخدمين يجب أن يفكروا مرتين قبل 
أن يبدأوا في استعارة خدمات الويب من المصادر المفتوحة. إذ قد تتحول إلى 
حصان طروادة. 


4-3-8 ناء خدماث الويب 


يمكن آن يتم تطوير خدمات الويب في مؤسسة المستخدم نفسها شأنها 
شأن حزم البرمجيات الأخرى» أو من قبل متعهد خارجي يتعاقد مع المؤسسة. 
أما الفرق فى ما يخص التطبيقات البرمجية التقليدية فهو أن خدمات الويب 
يجب أن تکون أصغرء وأن يكون بناۋها أسهل إذا ما عرفت جيداً. القرق الآخر 
هو أن خدمات الويب هي ملكية مشتركة في المؤسسة التي توفرها؛ أي إنها 
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تنتمي لجميع إدارات تلك المؤسسة. هذا كسر جدي للتقاليد السابقة عن كيفية 
تمويل برمجية في مؤسسة ما. 


فی الماضى» كانت دائرة تكنولوجيا المعلومات تعت تعتبر مأوىٌ برمجیاً داخلیاً 
مهمته توفير خدمات للإدارات الأخرى. فإذا أرادت دائرة التسويق نظام علاقات 
مع العملاءء فإنها تفوّض دائرة تكنولوجيا المعلومات بتطوير النظام أو شرائه 
لها. أما إذا رغبت دائرة التزويد والإمداد بنظام جديد لإإدخال الطلبيات» فإنها 
تفوض دائرة تكنولوجيا المعلومات ببنائه لها. إن إدارات المستخدمين هي التي 
لها سيطرة على الميزانية وهي الوحيدة المهيأة للدفع مقابل شيء ذي منفعة 
مباشرة لها. 


في حالة خدمات الويب» ليس واضحاً لأي الإدارات تنتمي. فإي شخص 
في الشبكة التنظيمية يمكنه الوصول إليها. إا من هو المسؤول عن الدفع مقابل 
الحصول عليها؟ الحقيقة هي أن خدمات الويب الجيدة تتطلب جهوداً كبيرة 
للتخطيط لها وتطويرها واختبارها. يجب أن تكون هذه الخدمات أكثر ثباتاً 
وموثوقية من النظم محدودة الاستخدام القديمة» كما يجب أن تكون قابلة 
لإعادة الاستخدام لأغراض مختلفة ضمن سياقات مختلفة. فهي كنظم 
المستخدمين الأخرى» تكلف خدمات الويب أكثر بثلاث مرات من النظام 
المصممة للمستخدم الواحد العادية. إن إدارات المستخدمين غير مهيّاة جيداً 
لتمويل المشاريع غير المخصصة لمتطاباتهمء وهذا يعد بمنفعة طويلة الأمد 
فقط. إذا كانت ثمة مشكلة يجب حلهاء فهم يرغبون في حلها مباشرة وفورياًء 
آي آنها يجب أن تعدل لتلبي متطلباتهم المخصصةء ولا شيء غير ذلك. 

إن تطوير خدمات الويب هو استثمار طويل الأمد . فخدمات الويب 
ستستغرق نحو عامين قبل آن تصبح ذات جودة كافية لتصبح جاهزة لاستخدامها 
فى عمليات الأعمال. من المشكوك فيه إذا كان المستخدمون على استعداد 
للانتظار طويلا. أما منافع استخدام خدمات الويب ذات التطوير الذاتي فستظهر 
خلال بضع سنوات قادمة. في الوقت الحالي» يجب أن تتحمل دائرة تكنولوجيا 
المعلومات استمرارية النظم الحالية. وهذا يضع عبثاً مضاعفاً على عاتق 
المؤسسة. لهذا السبب ولأسباب أخرى» فإ تطوير خدمات الويب الخاصة قد 
لا يكون بديلاً جاذباً. أما الحاجز الأكبر الذي يعترض التطوير فهو الوقت 
اللازم» والأمر الآخر هو التمويل. 
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8- 3 - 5 استعادة خدماث الويب 


آما البديل الخامس والأخير فهو استعادة خدمات الويب من تطبيقات 
البرمجيات الموجودة. صحيح أن البرمجيات الحالية قد تكون قديمة ويصعب 
إدارتهاء إلا أنها تعمل. ليس فقط تعمل» بل إنه يمكن تكيّفها لتلائم الإدارات 
المحلية. فهي تلائم البيانات وبيئة عمل المؤسسة. لذاء لماذا لا يُعاد 
استخدامها؟ يجب آن لا يكون الهدف استخدام التطبيقات الموجودة كلهاء 
وذلك آنها لن تكون ملائمة لعمليات الأعمال الجديدةء ولكنها ستلائم بعض 
أجزاء منها. قد تكون هذه الأجزاء عبارة عن عمليات أو إجراءات أو وحدات أو 
مكونات. الأمر المهم هو أن تكون قابلة للتنفيذ بشكل مستقل. لذا يجب آن يتم 
طيّها. إن تكنولوجيا الطي هي المفتاح لإعادة استخدام البرمجية الموجودة. إن 
اللغة التي كتبت بها البرمجية الموجودة ليست بالأمر المهم جداًء طالما أنها 
قابلة للتنفيذ في بيئة الخادم . 

بما إن طلبات الحصول على خلمات الويب يمكن أن يتم إعادة 
توجيههاء من الجائز وجود خوادم استضافة مختلفة لأنواع لغات البرمجة 
المختلفة على نحو جيد. بذاء قد يكون هناك خادم للغة 1هطاه٣‏ وآخر للغة 
1 وآخر للغة + +ع٤/۳.‏ الأمر المهم هو أن المكؤنات المستخلصة مجهزة 
بواجهة الاستخدام ا۷82 المعيارية التي تحول البيانات في الطلبات إلى 
بيانات محلية في البرنامج الذي يقوم بدوره بتحويل مخرجات البرتامج إلى 
بياتات في الطلبات. إن إنشاء مثل واجهات الاستخدام هله يمكن تنفيذه 
أوتوماتيكياً بحيث لا يتطلب ذلك جهوداً إضافية أكثر من الجهد اللازم لاختبار 
الواجهة. أما الخدمة ذاتها فقد تم اختبارها خلال سنوات الاستخدام 
الإنتاجية. أما أهم فائدة لهذه الطريقة فهو التكلفة المنخفضة والزمن القصير 
اللازمان لتصبح الخدمات جاهزة للاستخدام. 


تتمثل مساوئ هذه الطريقة في النقاط الآتية : 

© البرمجية تكون قديمة أو لا تكون مفهومة بسهولة. 

8 تحويل البيانات من الصيغة الخارجية إلى الصيغة الداخلية يقلل من الأداء. 
© قد لا يكون هناك مبرمجون ممن يألفون اللغات القديمة. 

هتاك مشكلة إضافية هي الحفاظ على حالة البيانات من عملية إلى أخرى 
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إذا كانت البرمجية غير مصممة أصلاً ليتم إعادة التشارك بها. إن إعادة التشارك 
يجب أن يتم تحديثها في النظام. هنا يتبادر السؤال عن كيفية الحفاظ على 
حالات العديد من الحالات التي يأتي بها المستخدمون» لكن تلك ليست 
مشكلة خاصة بطريقة استعادة خدمات الويب» بل هي مشكلة تنطبق على 
جميع الطرق. 
8 4 التنقيب عن خدمات الويبب 

التركيز الأساسي لهذه المساهمة هي كيفية استعادة خدمات الويب من 
التطبيقات الموجودة» ویشار إلى ذلك بالتتقیب عن خدمات الويب. .تم تطبیق 
الكثير من وظائف الأعمال فعلياً في مؤسسة مسبقاً. المشكلة هي آنه لا يمكن 
الوصول إليها بسهولة. الوظائف تكون مدفونة في نظم البرمجيات القدية(: 

وحتی تکون هله الوظائف متوافرة ليعاد استخدامها کخدمات ویب» یجب 
أن يتم استخراجها من السياق الذي نُقَّذت فيه» ومن ثم تكييفها لتلائم 
المتطلبات التقنية للهيكلية خدمية التوجه. وهذا يتضمن أربعة أنشطة مختلفة : 

الاكتشاف. 


ھ ال 


e‏ الاستخراج. 
6 التكييف. 


8 - 4 - 1 اكتشاف خدمات الويب المحتملة 


لدی ی ا ا من الشيفرة 
البرمجية القديمة مكرسة لتنفيذ بعض الوظائف التقنية أو لتخدم بعض مواقع 
تخزين البيانات القديمة أو تكنولوجيا تواصل البيانات. أظهرت البيانات أن ذلك 
يقذر بحوالى ثلثي الشيفرة الإجمالية. وهذا يعني أن ثلث الشيفرة البرمجية متاح 
لتحقيق آهداف التطبيق. إنها تلك الشيفرة البرمجية التى تهمنا فى عملية 
الاستعادة. المشكلة هي أن الشيفرة البرمجية المركزة للتطبيق متشابكة كثيراً مج 
الشيفرة التقلية. فقی وحدة شيفرة برمجية واحدة» آي عملية أو وحلة أو إجراءء 
قد يكون هناك أجزاء خاصة بإعداد قناع عرض البيانات أو أجزاء خاصة بحساب 
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ضريبة القيمة المضافة. وبالبحث فى الشيفرة البرمجية» يجب أن تكون أداة 
التحليل قادرة على إدراك هذه الأجزاء التى توفر قيمة للعمإ ”° . 

من ناحية أخرى» ليست جميع وظائف الأعمال صحيحةء إذ يصبح العديد 
متها قديم خلال الوقت. لذاء لا يجب أن تكون الشيفرة البرمجية لوظائف 
البرنامج مُعرّفة فحسب» بل يجب أيضاً أن يتم التحقق من كونها ذات قيمة 
حالياً. وهذا يؤدي إلى ظهور قضيتي بحث هما: 

1. كيفية تحديد الشيفرة البرمجية التي تؤدي وظيفة البرنامج. 

2. كيفية تحديد ما إذا كانت الوظيفة لا تزال ذات قيمة حالياً للمستخدم. 


ستتطلب هاتان القضيتان بعض آشكال صنع القرار القائم على القواعد. 
الأمر المهم هو أن المستخدم قادر على ضبط القواعد لتلائم احتياجاتهء أي إن 
أدوات التحليل يجب أن تكون ذات قابلية عالية للتخصيص. كما يجب أن تكون 
سريعة جداً طالما أنها ستقوم بمسح عدة ملايين من أسطر الشيفرة البرمجية 
لتحديد الأجزاء التي يُحتمل أن تكون خدمة ويب. لذا فالأمر المطلوب هنا هو 
آلة بحث معقدة لمعالجة الشيفرة البرمجية المصدرية. من المحتمل أن لا يكون 
ممكتاً اختيار خدمات الريب المحتملة من دون مساعدة بشرية. لذا سيكون هناك 
أيضاً بعض التفاعل من قبل المستخدمين مع الأداة لإعطاء المستخدم فرصة 
التدخل في البحث واتخاذ القرارات التي لا يمكن للأداة اتخاذها. مثل أدوات 
التنقيب التفاعلية هڏه هي موضوع بحث کبیر. 

كان المفتاح الأساسي لاكتشاف خدمات الويب المحتملة في الشيفرة 
البرمجية الموجودة قد وصف من المؤلف نفسه فى ورقة عمل سابقة قدمت 
حول استعادة قواعد العمل“ . الهدف هر تحديد أسماء حصيلة البيانات 
الأساسية ولتتبع كيفية إنتاجها. يمكن تحقيق ذلك من خلال تحايل تدفق البيانات 
المعكوس. قد يمر تتبع تدفق البيانات من خلال عدة عمليات آو إجراءات في 
أنواع أو وحدات مختلفة. من الضروري تحديدها جميعاً. من الأمثلة على ذلك 
معدل الائتمان في النظم المصرفية. الحصيلة الأساسية هي معدل الائتمان لکن 
قد يكون العديد من الوحدات أو الأنواع مشتركاً في إنتاج تلك الحصيلة. بناء 
على ذلك يجب أن يتم جمعها كلها لإنتاج خدمة ويب واحدة - آي حساب 
معدل الائتمان. هذه المشكلة ترتبط بمشكلة تأثير التحليل في صيانة البرمجية. 
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8- 4 - 2 تقييم خدمات الويب المحثملة 


من قضايا البحث الأخرى في ما يتعلق باكتشاف خدمات الريب المحتملة 
قضية تقييم مقاطع الشيفرة البرمجية المنتقاة كخدمات ويب محتملة. هتاء يجب 
آن يحدد مالك الشيفرة البرمجية ما إذا كان استخراج مقاطع الشيفرة البرمجية 
من النظم التي تتواجد فيها أمر يستحق العناء. وهذا سؤال يطرح حول إمكانية 
إعادة الاستخدام. 


يجب أن يتم تطوير المقاييس التي ستشير إلى ما إذا كان بالإمكان إعادة 
استخدام الشيفرة البرمجية آم لا. لقد تعامل المؤلف مع هذه المشكلة من قبل 
وأصدر ورقة عمل حولها" . المقياس الأساسي هو إعادة الاستخدام. تكون 
قطعة من البرمجية قابلة لإعادة الاستخدام إذا كانت منفصاة بسهولة عن الشيفرة 
البرمجية المحيطة بها. هناك بعض الروابط الوظيفية (أي استدعاءات الوظائف 
في الشيفرة البرمجية المحيطة)ء» وهذه تتشارك في بعض البيانات م إجراءات 
أخرى. وهكذا فإنه يجب عد الاستدعاءات الغريبة والفروع الأخرى خارج كتلة 
الشيفرة البرمجية موضع التساؤل» إضافة إلى البيانات غير المحلية - آي البيانات 
المصرح عنها خارج كتلة الشيفرة. يجب أن تكون هذه مرتبطة بحجم كتلة 
الشيفرة البرمجية أو الكتل مقدرة بعدد التعابير البرمجية. 

قد تكو تلك نقطة بداية جيدة» لكتها ليست كافية. هتاك أسئلة أخرى 
عن جودة الشيفرة البرمجية وقيمة الأعمال. السؤال هنا إذا ما كانت الشيفرة 
البرمجية جيدة بما فيه الكفاية وقيمة لترحيلها إلى الهيكلية الجديدة. يمكن 
استخدام مقاييس الجودة المتوافرة لتحقيق هله الغاية. يجب آن تقاس قيمة 
العمل من حيث مدى آهمية النتائج التي تنتج من جزء محدد من الشيفرة 
البرمجية. هناك أبحاث قليلة في هذا المجال. أخيراًء يجب أن يتم حساب 
كلفة استخراج الشيفرة البرمجية بالنسبة إلى الفوائد التي نجنيها من إعادة 
الاستخدام. يحتاج الأمر إلى المقاييس لقياس قابلية صيانة وقابلية اختبار 
وتوافقية وقابلية إعادة استخدام الشيفرة البرمجية» إضافة إلى قيمة الوظائف 
التي توديها تلك الشيفرة البرمجية. 

إن تقييم خدمات الويب المحتملة ليست مسألة تافهة وتتطلب مقاييس مثبتة 
لاتقانها. هذا هو المكان الذي تستدعى فيه المقاييس لاستخدامها لتوجيه القرار 
إذا ما سيتم إعادة استخدام الشيفرة البرمجية أم لا 
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8- 4 - 3 استخراج الشيفرة البرمجية لخدمة الويب 


حالما يتم تحديد أن مقطع الشيفرة البرمجية هو خدمة ويب محتملة» 
تكون الخطوة التالية هي استخراجها من النظام المضمنة فيها. قد يكون ذلك 
مهمة معقدة جداء خصوصا عندما لا تكون الشيفرة البرمجية عبارة عن وحدة 
يمكن تنفيذها بشكل منفصل. يمكن آن تشارك الوحدات الإجرائية بيانات مع 
وحدات أخرى في موقع التخزين الأساسي. وقد يتم استدعاء وحدات أخرى 
أيضاً. يجب أن تغطى جميع هذه التبعيات حتى يمكن استخراج الشيفرة البرمجية 
الإجرائية من بيثاتها. إن استخراج الشيفرة البرمجية كائنية التوجه أسهل عموماً 
من استخراج الشيفرة البرمجية الإجرائية» لكن هناك مشكلات أيضاً هنا. فقد 
یتوارٹ نوع معيّن أنواعاً آخری ذات مستوی أعلى» حيث لا يرغب أحدنا في 
استخراجها. كما قد يستدعي النوع عمليات تابعة لأنواع غريبةء وقد ينتج منها 
نتائج مهمة. يجب الحد من هذه التبعيات إما عن طريق تسوية النوع أو إدراج 
العملية. لكن ليست هذه بالحلول البسيطة. فالأبحاث مطلوبة لعحديد أفضل 
الوسائل لاستخراج الأنواع والشيفرة الإجرائية. 


مشكلة صعبة تعوق استخراج الشيفرة البرمجية من النظم القديمة وهي 
استخراج الميزات”". في البرمجيات كائنية التوجه تحديداًء تكون الميزة 
مبعشرة في العديد من الأنواع المحتواة في المكونات العديدة. الميزة هي 
سلسلة من العمليات الموزعة التي تتحفز بواسطة حدث» وينتج منها 
مخرجات محددة مسبقاً كالرد على استفسار أو نتيجة محسوبة» على سبيل 
المثال سعر مادة معيّنة أو معدل الائتمان. للحصول على هذه النتيجة» يجب 
أن يتم تنفيذ عمليات مختلفة في أنواع مختلفة بترتيب معيّن معطى. ستتوافق 
خدمة ويب مقترحة مع إحدى الميزات على الأرجح. إن استخراج الميزات 
من المكونات يشكل تحديا صعبا للباحثين في مجال البرمجيات. إن إمكانية 
استخراج تلك العمليات التي تجتازها الميزة فحسب أمر مشكوك فيه» ذلك 
أن هذه العمليات تستخدم خصائص النوع التي قد تؤثر في عمليات أخرى. 
من ناحية أخرى» سينتج من استخراج جميع الأنواع خدمات ويب كبيرة جداً 
تتضمن كمية كبيرة من الشيفرة البرمجية غير المرتبطة بمهمة خدمة الويب التي 
في متناول اليد. إن حل هذه المشكلة - إذا كانت قابلة للحل - سيتطلب 
جهوداً كبيرة من الباحثين. 
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8- 4 - 4 تكييف شيفرة خدماث الويب 

قضية البحث الأخيرة هي تكييف وحدات الشيفرة البرمجية المستخرجة 
لإعادة استخدامها كخدمات ويب. وهذا يستلزم تزويد هذه الوحدات بواجهة لغة 
وصف خدمات الويب ا۷82. وسيطاث الإدخال التى تستلمها وحدات 
الشيفرة البرمجية مسبقاً من قائمة عوامل» وقناع واجهة الاستخدام» وملف 
الإدخال وبعض وسائل إدخال البيانات الأخرى يجب أن يعاد تخصيصها 
كوسيطات ضمن طلب لغة وصف خدمات الويب. وهذا يعنى تحويلها من 
1× وتقلها من رسالة بروتوكول وصولية الكائن البسيطة 804۴ المستلمة إلى 
موقع تخزين داخلي في خدمة الويب. نتائج المخرجات التي آعيدت من قبل 
على هيكلية أقنعة إخراج وقيم إرجاع وملفات مخرجات وتقارير ووسائل إخراج 
بيانات أخرى يجب أن يعاد تخصيصها كنتائج لاستجابة لغة وصف خدمات 
الويب. وهذا يعني نقلها من موقع التخزين الداخلي لخدمة الويب إلى رسالة 
بروتوكول وصولية الكائن البسيطة الخارجة وتحوياها إلى صيغة رموز ×١‏ . 

هذا ويمكن أتمتة جميع هذه الخطوات. في الواقع؛ إن تكييف الشيفرة 
البرمجية هي التشاط الذي يفسح مجالا آفضل للأتمتة. مع ذلك» لا تزال هناك 
حاجة إلى إيجاد أفضل الطرق لعمل ذلك. يتطلب الأمر إجراء أبحاث عن تطوير 
أداة للتكييف. يصف ما تبقى من هذا الفصل منهجية المؤلف لأتمتة تكييف 
خدمات الويب المحتملة. 


8- 5 تطبيق تقنيات التجهيز 

ليس من طريقة فُضلى شاملة لتجهيز البرامج التطبيقية. يعتمد خيار تقنية 
التجهيز على نوع البرنامج. في مجال معالجة بيانات الأعمال» هناك ثلائة أنواع 
برامج رئيسة: 

e‏ برامج معالجة اللإصدارات الصخيرة. 


, 


® برامج فرعية عا 
لا يهم اللغة المستخدمة ما إذا كانت لغة التجميع أو ۲1/۲ أو کوبولء 
فجميع البرامج ذات النوع الواحد تشترك في بعض الميزات. 


247 


تحكم برامج المعاملات التي تجرى من خلال الإنترنت بواسطة نظام 
متابعة معالجة عن بعد ك .Tuxedog CICS, IMS/DC‏ يعتمد يثاء هذه النظم 
التحكم» ويستدعي نظام متابعة المعاملة لتنفيذ الخدمات له. في حالات أخرى 
(مثلاً »)٥1٥5‏ يكو التطبيق عبارة عن برنامج فرعي لنظام متابعة المعاملة وينفذ 
وظائفها عند استدعائه من قبل نظام المتابعة. فهو محكوم بالأحداث. يتم إدارة 
جميع بيانات التراصل من خلال متابعة معالجة 9 بعد. البرنامج التطبيقي مزود 
بمۋشرات لعنوتتها وتحفظ في مجال تواصل مشتر 


في الحالتين› لا تکون برا مج الإنترنت مجرد برامج کوبول أو ۴1/1 . . فهي 
خصائص لخة كاملة مفروضة من قبل متابعة المعالجة عن بعد على هيئة تعليمات 
إضافية آو ماكرو أو بياتات استدعاءات خاصة. تفرض نظم C1٥5‏ ماكرو خاص بها 
هو E۴٣ ٥1٥58‏ على البرنامج المستضيف بحيث تصبح مضمنة في كتلة الشيفرة 
البرمجية. اما نظم 1⁄8 فتذرض هیکلیات بیانات خاصة وعوامل متخیرة على 
البرتامج المستضيف. يجب أن يدرك محلل (50۲٣م)‏ برامج الإنترنت هذه ويحلل 
بناءات اللغة الخاصةء کیا لو كان يتعامل مع بيانات لخة البرامج المستضيفة. 


عند تجهيز برنامج إنترنت» من الضرورة بمكان إيقاف تشغيل جميعم 
العمليات التي تتواصل مع البيئة » بينما يجب الإبقاء على العمليات الأخرى التي 
تحدد مواقع التخزين آو تعالج الرساتل التي تفيد بوجود أخطاء. المتطلب هنا 
هو استبدال الأقنعة بالحقول المصححة وضبط خصائصها بوثيقة من نوع 
M1‏ والإبقاء على منطق البرنامج كما كان. كما هو موضح لاحقاًء يمكن 
تحويل برامج الإنترنت أيضاً إلى برامج فرعية ذات واجهة ربط. مع ذلك؛ 
يستلزم ذلك تغبير هيكلية البرنامج. في كلعا الحالتين» تتضمن مهمة التجهيز 
توفير بيانات لبرنامج الإنترنت» ويمكن إنجاز ذلك آفضل ما يكون من خلال رد 
انعدام حالة البرنام 0 . 

تحكم برامج الإصدارات الصغيرة بواسطة ملفات الإدخال التي تعالجهاء 
وقد تكون هذه الملفات عبارة عن ملفات معاملات أو ملفات عوامل تغيير 
بصورة طبيعية » سيقرأ برنامج الإصدار الصغير تسلسلياً في ملف إدخال أو أكثر 
أو في قائمة انتظار الرسائلء معالجاً أحد السجلات أو أكثر أو الرسائل في 
الوقت الواحد إلى أن يصل إلى النهاية. وقد تكون النتيجة عبارة عن تحديث 
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قاعدة البيانات أو تدفق من رسائل المخرجات أو ملف مخرجات أو تقرير. 


الهيكلية الرئيسة لبرتامج الإصدار الصغير هي عبارة عن حلقات متداخلة؛ 
كل واحدة تمثل مستوىّ دلالياً واحداً من البيانات كما اعترف بذلك مايكل. أ. 
جاكسون («0ەkع[‏ .۸ .اعوطMi)‏ منذ فترة طويلة" . يتم إنهاء الحلقات 
بواسطة تحولات مجموعة e‏ إن ما يميز بين برنامج الإصدار الصغير من 
برنامج الإنترنت هو آنه لا يمكن أن ن ينقطع وأنه مخصص لمهمة واحدة. ويناء 
على ذلك» يملك هذا البرنامج ذاكرة تتحول من حالة إلى آخرى. 

إن ساس تجهيز برنامج الإصدار الصغير هو استبدال إحدى وسائط 
الإدخال بأخرى - على سبيل المثال» استبدال ملف تسلسلى من سجلات ذات 
تنسيق ثابت بقائمة انتظار رسائل وثائق 1×. يبقى منطق البرنامج كما هوء 
وتبقى محتويات بيانات الإدخال كما هي» النموذج فقط هو ما يتم تبديله. 


تحكم البرامج ج الفرعية بواسطة عوامل تغيير خاصة بها. اعثماداً على 
الوسيطات يتم حساب نتائج معيّنة وإعادتها. إن منطق البرنامج الفرعي هو فعلاً 
من الخادم الذي ينفذ طلبات مرسلة من التابع - المستدعي. يجب أن يعامل كل 
طلب استدعاء مستقلاً عن الاستدعاءات الأخرى. إذا لم يكن البرنامج يحتفظ 
بالحالةء فيكون ذلك لهدف معيّن - ذلك بهدف استمرار المعالجة عند نقطة 
محددة كما في حالة عكس البرنام . 


هذا يجعل تجهيز البرامج الفرعية أسهل نسبياً. 3 المرء إلى محاكاة 
الواجهة. يبقى سلوك الوحدة ثابتاً. حتى آنه يمكن تحقيق الاستدعاء المرجعي 
عن طريق تخزين العوامل المتغيرة في البرنامج التجهيز وتمرير مرجعيات العنواك 
إلى إجراء هدفي. إذا استخدم نوع واجهة آخر»ء كوئيقة بصيغة 1× في موقع 
في هيكلية بيانات كوبول» يجب أن يتم تحويل الواجهة الجديدة إلى واجهة 
قديمة قبل استدعائها من قبل البرنامج الفرعي. عند استعادة الواجهة القديمة 
(مثلا» هيكلية كوبول) يتم تحويلها مرة أخرى إلى واجهة جديدة (مثلاً» وثيقة 
بصيغة 1×). هنا تنطبتق تقنیات 4۸۴1 قياسة2“ . 


8 - 5 1 تجهیز برامج ج اللإأنترنت بواجهة بصيغة ×M1‏ 
تستجيب البرامج التي تعمل من خلال الإنترنت إلى طلبات التزامن من 
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المواقع الإلكتروتية للمستخدمين» وهذا يعني آن المستخدم يملأ الصفحة 
الإلكترونية ويرسلها وينتظر الاستجابة. يجب آن تستجيب برمجية الجهاز الخادم 
بسرعة حتى لا يضطر المستخدم إلى الانتظار لفترة طويلةء وهذا يعني فيا 
أنه يجب أن يكون هناك مسارات قصيرة للمعاملات» وأن يكون خالياً من 
الحمليات والبيانات غير الضرورية. يجب أن يتم ضبط عملية تجهيز البرامج التي 
تعمل من خلال اللإنترنت لتلبية هذه الاحتياجات. عملية ص50۷4 الموضحة 
هنا تتكون من خمس خطوات تعمل كل منها حسب الحالة التي تتركها الخطوة 
السابقة لها : 


e‏ أولاً: يجرد البرنامج من جميع TP-Monitor lale‏ الموجودة» حیٹ 
يتم حذفها واستبدالها باستدعاءات كوبول قياسية لبرنامج التجهيز. 


# ثانياً: يجرد البرنامج من جميع كتل الشيفرة البرمجية غير المطلوبة 
لتنفيذ المعاملات المخصصة من قبل المستخدم. 


ه ثالثاً: يتم نقل كافة البيانات التي كانت تنتمي مسبقاً إلى خرائط 
الإدخال/ الإخراج» أو التي جُعلت قابلة للوصول للبرنامج من خلال مواقع 
التخزين المشتركةء وذلك إلى هيكلية بيانات واحدة في قسم الربط. 


® رابعاً: يتم تحليل استخدام البيانات في قسم الربط لتحديد ما إذا كانت 
بيانات إدخال آو إخراج أو كليهما معاً. 

۵ امسا يتم تحويل هيكلية بيانات الربط إلى جدول وصف بيانات 
بصيغة ۷1× لاستخراج قيم البيانات من نماذج ا × الواردة وتحويلها إلى 
هيكلية بيانات بلغة كوبول ولإنتاج وثيقة مخرجات بصيخة ×١1‏ من الحقول 
المستخدمة كمخرجات. 


إن سبب نزع عمليات ٥108‏ و٣1M5-2‏ هو تقليل معالجة الخريطة ولجعل 
البرنامج مستقلاً عن ملكية برنامج مراقب معالجة المعاملات ٣0ان«مM‏ ۴إ . 


(#) نظام معالجة المعاملات أو مراقب معالحة المعاملات هو مجموعة من المعلومات التي تعالج معاملات 
البيانات في نظام قاعدة البيانات الذي يراقب برامج المعاملات (نوع خاص من البرامج). ا ماهية برنامج 
المعاملات فهر أنه يدير البيانات الي بجحب أن تبقى في حالة مثسقة وثابثة + على سبيل المثال» إذا أجريت معاملة 
الدفع الإلكثروني»› بجحب آن يتم سحب البلغ المدفوع من حساب وإضافته إل حساب آخر؛ فالبرتامج لا پمكن 
أن يكمل واحدة من هاتين الخطوتين فقط (المترجم). 
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البرامج ج التي کانت محكومة باحداث CICS‏ أصبحت الآن محكومة 
س 
بالىىانات 


إن السبب المنطقي وراء نزع الشيفرة البرمجية غير الضرورية هو التخلص 
من التكرار. يكرّس جزء كبير من الشيفرة البرمجية لبرامج معالجة المعاملات 
التي تتم من خلال الإنترنت لأغراض الإدارة من أجل مراقبة المعالجة التي 
تتم عن بعد. يمكن حذف معظم هذه الشيفرة البرمجيةء إن لم يكن جميعهاء 
من دون التأثير في منطقية العمل. التقنية المستخدمة لإزالة الشيفرة البرمجية 
هي التشريح الإجرائي. يقوم المستخدم بالتأشير على الوظائف - الفقرات أو 
الأقسام - التي يرغب بالاحتفاظ بها. وبواسطة تحليل الاستدعاء المتكرر يتم 
التآشير على جميع الفقرات والأقسام المستخدمة فيها. بعد ذلك يتم إزالة 

جميع الشيفرة البرمجية غير المؤشرة» بما في ذلك الفقرات و/أو الأقسام. تم 
تخطية تقنية التشريب الإجرائي وتطبيقها في إزالة الشيفرة البرمجية في المادة 
المطبوعة 17 , 

إن جمع البيانات لإعادة هيكلتها کعوامل مت متغيرة أمر مهم وذلك لأنه 
لم يعد برتامج مراقب معالجة المعاملات پوفر الخرائط بعد الآن. الآآن يتم 
تمرير بيانات الإدخال كعوامل متغيرة إلى برنامج التجهيز الذي يقوم بدوره 
بتمرير بيانات الإخراج رجوعاً إلى المستدعي کعوامل مخرجات. وهذا يعني 
أن عناصر البيانات التي كانت سابقاً محتواة في الخرائط يجب أن يتم 
تحويلها الآن إلى قسم الربطء لكن ليس جميعها. الخرائط تضقدت أيضاً 
عدداً من حقول التحكم - على سبيل المثال» خاصية طول الكلمة بوحدة 
البيانات التي لم تعد ضرورية. يتم حذفها من هيكلية البيانات. إضافة إلى 
ذلك» يتم حذف جميع بيانات الإدارة غير المرتبطة بمهام عمل أيضاًء» وهذا 
يترك البيانات التي يتم الرجوع إليها فعليا من قبل البرنامج الجديد المختصر. 
أظهرت التجربة أن هذا يؤدي إلى تقليل حجم قسم بيانات البرنامج بنحو 50 
فى المعة 2 , 

احتفظ برنامج التجهيز الذي يعمل من خلال الإنترنت بهذه العوامل 
الثلاثة - معرّف العملية (10 لهطاءM)»‏ وشيفرة الترجيع «(Return Code)‏ 
وهيكلية البيانات (ءure†ءStru (aa‏ المرتبطة بربط وثائق 1اX×M‏ . 
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من خادم الويب 


/ 


ر 
هسم الريط في كوبول 1 
XM“ I> 1 XML -lnterface «XML-“OUE >‏ 


| <Contsols> 2 Controls. <controls> 
<Method>values /Method> 3 Method PIC X(30). «Retcode>valuec« /Retcode> 
<Retcode>value< /Retcode> 3 Ratcodoe PIC XX, </Cantrols> 

</Controls> 2 Mask <Mask> 

| Mask> 3 Field PIC XX. «Field>Value</?icld> 
<FieldzValue</Field> 3 Flold PIC 89. «Ficld>Value</Field> 
<Fielaz>value</Field> 3 Field PIC X(5). </Mask 
<Fiald>Valua</Pleld> 2 Common <Coamon> 

|  </Maak> 3 Fleld PIC X. <Field>Value>/Fiold> 

| <Commons 3 Field PIC 9, </ Common > 


| <F#ield>Vvalue>/Pield> 
<Field>Value>/Field> 


| «/Comeon> ا‎ 
| </KML-In> 
COBOL Online Program 


وثيقة إخراج بصيغة 81× لے 8 وثيقة إبخال بصيغة 41× 
Database‏ 


الشكل (8 -1): تجهيز برامج الإنترنت 


معرّف العملية مطلوب إذا رغب المستخدم باستدعاء وظيفة محددة من 
وظائف البرنامج من دون المرور بالوظائف الأخرى. إذا لم يكن معرّف العملية 
معدآء يتم تنفيذ البرنامج كاملاً. أما شيفرة الترجيع فهي مطلوية لإعادة حالة 
الخطا إلى الجهاز التابع في حال وجود خطا. أما معالجة الاستثناءات فثترك إما 
للتابع أو لبرنامج التجهيز (انظر الشكل 1-8). 

تقضمن هيكلية البيانات كلا من العوامل المتغيرة من موقع التابع 
الإلكتروني والنتائج الناجمة عن الخادم. إذا لم تكن العوامل المتغيرة قد حُررت 
بعد من قبل التابم» فيجب التحقق منها مرة أخرى قبل معالجتها وفقاً لمجموعة 
من الغواعد المنطقية - الشروط المسبقة. كما يجب أن يتم التحقق من نتائج 
برنامج الخادم أيضاً للتأكد من مطابقتها لمجموعة من الشروط اللاحقة قبل 
إعادتها إلى المستدعي 3 . 

للتمييز بين العوامل المتغيرة والتتائج» يتم إجراء تحليل لاستخدام البيانات 
للشيفرة الإجرائية. يتم التأشير على البيانات إما كبيانات إدخال أو إخراج أو 
إدخال/ إخراج. يتم تحديد ذلك مقابل إنشاء هيكليتي بيانات منفصلتين» واحدة 
لاإدخال وأخرى لاوٍخراج» لان هناك العديد من العوامل التي تكون من كلا 
النوعين» إدخال وإخراج» وهذا قد يؤدي إلى تعارض بعض الأسماء في 
الشيفرة البرمجية. أثبت ذلك أنه من الأفضل وجود هيكلية بيانات واحدة لكن 
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لتعليم عناصر البياتات الأولية وفقاً لاستخدامها. هذا يتيح استخدام هيكلية 
البيانات نفسها للإدخال والإخراج. طبعأًء لا يزال هناك وثيقتا 61× متفصلتين › 
إحداهما تلك التي يتم تهيئة هيكلية بيانات كوبول منهاء والأخرى هي تلك التي 
يتم إنشاؤها من هيكلية بيانات كوبول. أما الإجراء المتبع لإنشاء جدول وصف 
بيانات ×٣‏ فهو مشترك بين برامج التي تعمل من خلال الإنترنت والإصدارات 
الصغيرة» ويتم وصفها لاحقاً في قسم منفصل. 

بعد إكمال العملية ذات الخطوات الخمس» هناك نسخة التجهيز للبرنامج 
الذي يعمل من خلال الإنترنت السابق» حيث يمكن تجميع الإصدار وتحميله 
ليتم تنفيذه في بيئة الإنترنت. يبقى الإصدار الأصلي على حاله من دون تغيير في 
بيثة C108‏ أو .1M8‏ إذا حدث تغيير منطقي على البرنامج الأصلي»› فإن نسخة 
البرنامج المشتقة الخاصة بالإنترنت يجب أن يعاد إنشاؤها. لهذا السبب يجب أن 
تكون عملية التجهيز مؤتمتة. كل ما على المبرمج المسؤول عمله هو بدء العمل 
المؤتمت لإنشاء نسخة الإنترنت وتجميعها وربطها. 


8 - 5 - 2 تجهيز البرامج الفرعية بواجهة 01× 

البرامج الفرعية التي تعمل ضمن بيئة معالجة المعاملات التي تتم عن طريق 
الإنترنت تكون أكثر عرضة للتجهيز بما إنها تمتلك واجهة وتحكمها البيانات. 
المهمة الوحيدة هنا هي فصل عوامل الإدخال المتغيرة (أي المتغيرات) عن عوامل 
الإخراج (آي النتائج). إذا كان أحد العوامل عامل مدخلات وإخراج معاًء يجب 
أن يؤشر عليه بناءَ على ذلك. إذا كان العامل مؤشراً عليه كعامل مخرجات» يتم 
استخراجه وإدخاله في وثيقة الإخراج. إذا كان عامل مدخلات وإخراج معا يتم 
إعداده من وثيقة الإدخال وإدخاله إلى وثيقة الإخراج (انظر الشكل 2-8). 

وبالتالي» هناك خطوتان تتعلقان بعملية تجهيز البرنامج الفرعي : 

# أولاً» لتحديد كيف تستخدم عوامل الربط عن طريق تحليل مجموعاتها 

ه ثانياًء لإنشاء وصف بيانات ۷1× لبدء واستخراج العوامل. 

إن استدعاء روتين شيفرة تحويل العوامل ×1٨‏ لقسم الربط كاملا هي 
مهمة برنامج التجهيزء حیٹ يتم ذلك من وثيقة مدخلات KML‏ . بعك إعادة 
التحكم من البرنامج الفرعي» يتم استدعاء روتين شيفرة تحويل العوامل 


253 


71 لإنشاء ملف إخراج 1× من حقول المخرجات في قسم الربط. 
هناك برنامج تجهيز قياسي بدعى وهإ۷ ۷1× يستخدم لهذه الغاية. 


وثيقة مدخلات بصيغة 41× 


وثيقة مخرجات بصيغة 41× 


<Weekdays-Input > 
<Datum> 
<Day>12</Day> 
<Month> M< /Month> 
<YearzlNIxc/ Year> 


<#eekdays -Output > 
<Weekday>Dienstag< /Weekday> 


Input 
Input 2 Month 
Input 2 Year 
Input 1 Lang-Code PIB X. / 
output 1 #eekday PIC X(12) 


PROCEDURE DIVISION USING Datum, Larıg-Code, 
PERFORM Check-Datum 
PERFORM Select-Language. 
PERFORM Get-Hcekday. 
GOBACK. 


Weekday. 


الشكل (8 -2): تجهيز البرامج الفرعية 


8 - 5 - 3 تحویل ×٧1‏ إلى کوبول وبالعکس 

إن ساس تحویل بیانات × إلى بیانات كوبول هو جدول وصف 
بيانات × المنتج من وصف بيانات كوبول. لكل هيكلية كوبول» يتم إنشاء 
مدخل مجمع بعلامات بداية ونهاية. ولكل حقل من الحقول الابتدائية في لغة 
كوبول» يتم إنشاء علامة حقل ذات ست خصائص (انظر الشكل 3-8) : 

<1عvع[>‏ : = رقم مکون من خانتین 

>name>‏ : = اسم بلغة كوبول مكوّن من 0 رمراً 

<مصرا> : = نوع البيانات بلغة كوبول مكوّن من رمز واحد 

<ومص> : = موقع الحقل بمقدر بالبايت من بدايته 
طول الحقل مقدر بعدد الرموز 


<sعuععه>‏ : = عدد مرات وجود الحقل 


: <lng> 
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<وعصتاعل> : = حقل قد بيعيد تعريفه الحقل الحالي 

< عمو > : = استخدام الحقل إدخال/ إخراج/ إدخال إخراج 

عند تحويل بيانات 1× إلى كوبول» يتم التحقق أولاً من جدول وصف 
البيانات من حيث نوع الوثيقة المعرفة لضمان أن هيكلية البيانات صحيحة . 
إن لم تكن صحيحة» يتم رفض الوثيقة. وبخلاف ذلك»› يتم تحویل جدول 
وصف البيانات إلى جدول داخلي من خلال وحدة شيفرة تحويل العوامل وبتم 
تحديد منطقة تخزين سعتها كسعة آخر موقع زائد آخر طول. ومن ثم يقرا ملف 
محتوى آ۷×؛ يتم التحقق من كل بند ومطابقته بالجدول الداخلي» يتم تحويل 
قيمته وتخصيصها إلى الموقع المناسب ضمن مساحة التخزين المحددة» علماً 
بأن استخدامها سيقتصر على الإدخال أو الإخراج. يتم تعيين حقول البيانات غير 
المشار إليها في وثيقة 1× إلى القيمة الافتراضية كفراغات أو أصفار. 


XML Data Description COBOL Data Structure 


clLinkage-Section> 
«Parameter >» 
<Field> 
<level >1< / Level > 
<Name >Day < / Name > 
<Type>S< /Type> 


LINKAGE SECTION. 


* 1 Datum, 


</Field> 

«Fields - — 2 Day PIC 99. 
#LEVO] >2 /Leve İi > 
<Name>Day</Name> 2 Month PIC 99. 
<Type>8</Type> 


<Pos>1</?08> 
«<Lng>2</Lng> 
«Occurs>1</Occurs> 
«<Usagqe>Input</Usage> 

</Field> 

«<Fielaû> 
<bLevel >1< /Level> 
«Name >Lang- Code < /Name > 
<Type>X</Type> 
<Pos>9</Fos> 
<img»1</ bng> 
<Occurs>1</OceurE> 
«Usage>Input</Usage> 

</FPield> 


2 Year PIC 9993, 


* 1LangCodePCX. 


الشکل (8- 3): تحویل بیانات ۷1×/ کوبول 


عند تحویل بیانات كوبول إلى ×٥1‏ يتم إنشاء جدول وصف البيانات 
الداخلي» وتبدأً وثيقة × بترويسة وصفحة نمطية. ومن ثم يتم معالجة 
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جدول وصف البيانات بطريقة متسلسلة لتحديد جميع الحقول المؤشر عليها 
كحقول مدخلات أو مخرجات. لكل حقل من حقول المخرجات» القيمة 
الموجودة في الموقع المشار إليه في الجدول تحؤل من النوع المشار إليه في 
جدول وصف البيانات ویتم إدخالها كقيمة حرفية مع علامة اسم ملائمة في 
وثبقة مخرجات ا×. ثم تعاد وثيقة المخرجات إلى التابم. 

تنطبق هيكليات بيانات كوبول الهرمية تماماً مع هيكليات بيانات 1× 
الهرمية» بما آن كوبول تستخدم صيغ حقول ثابتةء فإن تحويلها من وإلى 
سلاسل برموز شيفرة 48٥11‏ أمر سهل. إن هيكليات بيانات ۷1× وكوبول 
متوافقة تماماً. في الواقع؛ يبدو الأمر كما لو أن هيكليات بيانات كوبول 
وهیکلیات بيانات 1× من مصدر وار , 


8- 5 - 4 عملية الأداة 
تتكون عملية الأداة (صلا۴ه8) التي طورها المؤلف لربط المكؤنات 


# الخطوة الأولى: خطوة التنقيب عن الوظيفة. يتم التأشير على الوظائف 
التي سيعاد استخدامها وتستخرج من البرنامج الموجود مع البيانات التي 


تستخدمها. 
© الخطوة الثانية: خطوة التجهيز. يتم إنشاء واجهة جديدة لکل وظيفة 
مستخر جة. 


# الخطوة الثالثة: خطوة إنشاء .×M1‏ يتم إنشاء مخطط فرعي بصيغة 
×٣‏ من وصف الواجهة في لغة البرمجة الأصلية للبرنامج. 

8 الخطوة الرابعة: إنشاء شيفرة تحويل العوامل للخادم لتحليل رسائل 
×٣‏ الواردة وترتيب الرسائل الصادرة. 

« الخطوة الخامسة: خطوة تحويل التابع. يتم إتشاء أصناف جافا (بول 
sعو)‏ من المخطط الفرعى بصيغة ×۸٣‏ وذلك للإرسال واستقبال 
رسائل .XM1‏ 

© الخطوة السادسة: خطوة الربط بالخادم. يتم ربط جميع كتل «شيفرة تحويل 
العوامل 5 مع وظائف الخادم في المستضيف وذلك لاانشاء sالd.‏ 


256 


6 الخطوة السابعة: خطوة بناء التابع. يتم بناء أصناف جافا المتكونة في 
مكون واجهة ربط جافا» وذلك لربط الموقع الإلكتروني مع خدمات 

الويب في المستضيف (انظر الشكل 4-8). 
التنقيب عن الوظائف . في خطوة التنقيب عن الوظائف» تعرض الأداة 
So tWrap‏ مصدر البرنامج المتوارث الذي تستخرج منه الوظائف لإعادة 
استخدامها كخدمات ويب. في حال استخدام لغة التجميع»؛ فقد تختار 
المستخدم ۳8٤٣۲8‏ أو علامات تمييز مفردة. أما في حال وجود ۲۶1/1 فقد 
بختار المستخدم الإجراءات الداخلية أو الكتل المتداخلة. وأما في حال استخدام 
لغة كوبول فقد بختار المستخدم الأقسام أو الفقرات. وأما في حال استخدام € 
فقد يختار المستخدم الوظائف أو الإجراءات. في كل الأحوالء يتم استخراج 
وحدة الشيفرة البرمجية المختارة معاً مع جميع الوحدات التابعة - أي آنه يتم 

الإشارة إلى برامج الروتين الفرعية بتلك الوحدة. 


الشكل (4-8): عملية إنشاء خدمة ويب 


257 


بما إن البرامج الروتينية الفرعية قد تشير إلى برامج روتينية فرعية أخرى؛ 
فإن عملية إرفاق شيفرة برمجية مستقلة تكرر إلى أن يتوقف العثور على المزيد 
من البرامج الروتينية الفرعية. وهذا يقابل التشريح الإجرائي وهو خوارزمية 
تكرارية لجمع نقاط المخطط الإجرائي الرسومي الذي عرض في ورقة بحث 

سابقة" . إذا تم جمع العديد من البرامج الروتينية الفرعية» فقد تصبح خدمة 
الويب النظرية كبيرة جداً ويجب | اما لذاء من الأفضل دراسة تأثير مجال 
عمل الوظيفة المختارة قبل استخراجها. كما أنه من الضروري الحد من تفرعات 
في المجال المختار لضمان أن الوظيفة يمكن أن نقذ باستقلالية. 


تجهيز الوظيفة. حالما يتم استخراج الوظيفة من المصدر الموجود مع 
الوظائف الفرعية التابعة لهاء تكون الخطون التالية تجهيز الوظيفة. يتم ذلك 
أوتوماتيكياً باستخدام الأداة مه80۴ التي د تنشئ مدخلا وواجهة لتلك الوظيفة. 
يسبق عملية إنشاء الواجهة تحليل لتدفق البيانات التي تحدد جميع المتغيرات 
المشار إليها من قبل الوظيفة سواء كان ذلك مباشرة أو بشكل غير مباشر. 
ويتضمن ذلك هيكليات البيانات الأساسية والمتجهات المقهرسة. إذا كان أحد 
العناصر الأولية في الهيكلية مشاراً إليه» فإن جميع الهيكلية ستكون مضمَنة في 
الواجهة. 


في النهايةء تصبح كافة البيانات المستخدمة في وظيفة التجهيز جزءاً من 
واجهتها. إذا كانت الوظيفة صغيرةء ستكون الواجهة ضيقة. أما إذا كانت الوظيفة 
كبيرة» فإن الواجهة تصبح أوسع. ويعود تضييق نطاق الوظائف للمستخدم. 
في أي حالة من الحالات» تكون الوظائف عبارة عن مكونات عديمة 
الحالة. فهي لا تحتوي أي بيانات ثابتة. وهذه الخاصية تجعل من المكرنات 
قابلة لاستخدامها في المعالجة متعددة المواضيع. البيانات تكون تابعة للمهمةء 
في حين تكون الشيفرة البرمجية قابلة لأن تكون مشتركة 
إتشاء مخطط ا۷ ×. بعد تجهيز الوظائف القابلة لإعادة الاستخدام المختارة 
وإنشاء الواجهات الوظيفية الجديدةء تآتي الخطرة التالية وهي تحويل هذه 
الواجهات إلى مخطط × في حين يتم في الوقت نفسه ! إنشاء شيقر شيفرة التحويل 
الخاصة بالخادم لمعالجة رسائل 1× بناء على ذلك المخطط. عندما يتم تجهيز 
الوظائف› ES OPES‏ 
1 أو كوبول أو .٤‏ تصبح الواجهات إما ماكرو لغة التجمیع أو توابع ۲1/۲ أو 
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نسخ كوبول أو ملفات ترويسية للغة .٤‏ بهذه الطريقة تكون الواجهات مستقلة 
عن الوسيط. وقد يتم ترجمتها ! ما إلى 84-51 C0۸‏ أو إلى اM×.‏ إلى هتاء 
يتم حفظ الواجهات في مكتبة الماكرو في الخادم المركزي. 

تحوّل الواجهات إلى ۷× لغايات ربط الوظائف المستخرجة مع الويب. 
كل واجهة من الواجهات هي بالضرورة هيكلية معرفة كنوع معقد من اM×.‏ 
اما خصائصها فهي الاسم والتوع وموقع الاسم. إذا كان هناك هيكليات فرعية 

ضمن الهيكلية الأصلية› فإنها ستصبح آنواعاً معقدة أيضاً. في حالة إعادة 

المجموعات» يكون أقصى عدد مرات التكرار معطى. 

العوامل المفردة هي عناصر ذات خصائص قياسية متوقعة مسبقاً من قبل 
»×«M1‏ وهي تحدیداً Hrefy, Type Name‏ وOccurs‏ وغيرها. إضافة إلى ذلك 
هناك خصائص ممتدة مخصصة لتسهيل تحويل البيانات إلى آنواع ۴8٥01٤‏ في 

:۴٥١١ 8‏ = إزاحة حقل البيانات ضمن هيكلية بيانات المستضيف. 

8 ع«1: = طول حقل بيانات المستضيف مقدراً بالبايت. 

® ١ذ۴‏ := نمط نوع التحرير بلغة كوبول أو ۲۶1/1. مثلاً 8999.99 . 

Use ®‏ := الاستخدام» مثلاً حسابي» عرض وغير ذلك. 


تتيح هذه الخصائص لأداة التحليل وضع بيانات المدخلات في الموضع 
الملائم» بالطول الملائم وبصيغة ملائمة ضمن حاجز" الرسائل التي تتضمن 
عوامل الوظيفة المستدعاة. عكسياً» قد تستخرج بيانات المخرجات من حاجز 
الرسائل لوضعها في و یق XML‏ صادر مخطط ۔اM×‏ هذا هو آساس جم 
XML‏ . 


إنشاء شيفرة التحويل للخادم. في الخطوة الرابعة من مخططات اM×»‏ 
يتم إنشاء آدوات تحلیل معالجة رسائل XML‏ الواردة من التوابع وثرثیب 
عودتها إلى التوابع. بهدف التوافق مع نظام وقٽت التشغيل الذي يتم تشغیل 


(«) العازل أو الحاجز (2ء7لس8) هو مكان مؤقت في الذاكرة حيث يتم فيه تخزين البيانات حين تنقّل من 
مکان إلى آخر (المترجم). 
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الوظاتف المستهدفة فيه» يتم إنشاء شيفرة التحويل لأداة التحليل بلغة البرمجة 
نفسها التي استخدمت لبناء الوحدات الوظيقية. في حال استخدام لغة كوبول» 

تبرمج شيفرة التحويل لأداة التحليل بلغة كوبولء أما في حال استخدام ۴1/1 
فتبرمج بهذه اللغة» وهكذا. وهذا من شأنه أن يتجنب المشكلات التاجمة عن 
التواصل عبر اللغات. 

عند بدء العملية» يتم قراءة مخطط ]× من موقع تخزين 01× ويتم 
إنشاء جدول وصف البيانات الداخلية مع مدخل لكل عامل من العوامل. يتضمن 
المدخل الاسم والصورة والاستخدام والإزاحة والطول وتكرار الحدوث. ومن 
ثم عند استدعاء الوظيفة ا فإنها تستاعي شيفرة تحويل المدخلات 
لإعطائها للرسالة الواردة. تقر شيفرة التحويل وثيقة 1× التالية من طابور 
الإدخال» وتلتقط قيم ا من الوثيقة وتحولها إلى إلى أنواع بيانات المستضيف. 
بعد ذلك يتم تخصيص القيم المحولة إلى الحقول المقابلة في الفراغ المخصص 
للعنوان في برنامج التجهيز. 

يتم تشخيل شيفرة تحويل المخرجات عندما يستلزم الأمر كتابة خريطة أو 
سجل أو تقرير» أو عند الخروج من وظيفة التجهيز. في أي حالةء تأخذ شيفرة 
التحويل نتائج بيانات المخرجات من الفراغ المخصص للعنوان في البرنامج 
المجهز وتحولها إلى قيم رموز 1آ©45 وتدخلها في وثيقة إخراج »M1‏ 
لتحريلها إلى التابع. إن الاحتفاظ بجدول وصف البيانات الداخلي في ذاكرة 
الاحتفاظ في الخادم» لن يلزم مخطط × سوى تفسيره مرة واحدة فقط 
وذلك في بداية كل عملية. 

إنشاء صف التابع . مخططات ×1٣‏ التي تعتبر أساس إنشاء شيقرة 
التحويل في الخادم تستخدم نفسها لإنشاء آصناف التابعم. لكل وظيفة في الخادم 
(آي خدمات الويب) يتم إنشاء صنفين اثئين من نوع جافاء أحدهما لإنشاء 
الطلب لوظيفة الخادم» والآخر لتفسير النتيجة الناتجة من الخادم. تستدعى 
عمليات النوع من قبل أصناف واجهة المستخدم التي تعالج صفحة والويب 
الخاصة بالمستخدم. 

هذان الصنفان الناتجان لهما غرض مضاعف. فمن ناحية» يحفظان 
مبرمجي التابع من الوقوع في مشكلة كتابتهماء ومن ناحية أخرى يضمنان أن 
تون واجهات 1× بالنسق نفسه. 
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ربط خدمات الويب. في الخطوة الأخيرة» يتم ربط وظائف الخادم معا مع 
وحدات تحميل رابط ديناميكي مستقل ليكون متاحاً في الجهاز المستضيف› 
الذي قد يعمل ضمن ١١ءطم؟طء¥‏ أو عاعمآطء. تعمل وحدات لال بطريقة 
خدمات الويب نفسها ويمكن أن تكون متوفرة ل 00۲6٤‏ أيضاً. يمكن 
استدعاؤها من أي متصفح إنترنت من أي مكان في الشبكة. يجب أن يتضمن 
استدعاء عنصر التابع الأنواع (عوها٣)‏ لإرسال واستقبال واجهات 1× إلى 
وظائف الخادم. بطبيعة الحال بالنسبة إلى أنواع ٤۷6ا00»‏ يتم إنشاء الأنواع بلغة 
C+ +‏ لغايات التوافقية. 

الفارق المهم بالنسبة إلى خدمات الويب المقترحة من مايكروسوفت هو 
حقيقة أن هذه الخدمات تنتج أوتوماتيكياً من البرامج القديمة الموجودة من 
دون تدخل يدوي. وهذا يميزها من أساليب إعادة التصميم المعتادة. فهي 
تمثل توفيراً مهماً في جهود التصميم والبرمجة والاختبار. إضافة إلى ذلك» 
فهي تلبّي متطلبات إعادة استخدام وظائف البرامج القديمة المتطلبة هنذ زمن 
من دون الحاجة إلى إعادة برمجتها. يتم الوصول إلى وظائف التطبيق 
الموجودة من خلال الإنترنت» كما تصورها كل من تيبثت كا†ءططذا 
وەeناء‌B‏ (انظر الشكل 8)58 , 


Client 
Component 


6 XML 
Request 0 کا‎ 


Server Server Server 
Component Component Component 


Dynamic Link Loads on Server (Web Services) 


الشكل (5-8): هيكلية خدمة الويب 
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8 - 6 الخبرة العملية 

طبقت الطريقة الموصوفة آعلاه على برنامج بنكي واسع النطاق» مكتوب 
بلغة البرمجة کوبول» ویعمل ضمن 158-5٣‏ مع قاعدة البيانات العلائقية 
2. شمل النظام 92 وحدة كوبول إضافة إلى 11 وحدة بلغة التجميع ارتبطت 
هذه الوحدات ب 65 جدولاً في قاعدة البيانات. أما الغاية من هذا البرنامج فكان 
معالجة المعاملات الواردة من آلة الصرّاف الآلي .AM‏ کان هدف المشروع 
جعل نظام الكوبول قابلا للتنفيذ في ٥1٥5‏ وفي خادم التطبيقات ١1511ء۷‏ من 
.]8M‏ لتحقيق هذا الهدف» حذفت عمليات 1۷18-2٥‏ واستبدلت بأداة تجهيز 
تعمل على بناء طابور للمعاملات الواردة من آلة الصراف الآلى وتغذيها 
بالتسلسل إلى وظائف العمل الأساسية التى تعمل بدورها على استدعاء روتين 
الوصول إلى قاعدة البيانات. بهذه الطريقة» أمكن حفظ كتلة الشيفرة البرمجية 
للغة كوبول» على الرغم من أن النظام نفسه كان مضمَناً ككائن في الهيكلية 
الموزعة. 

كان بالإمكان استدعاء الوحدات المنفصلة من النظم الغريبة طالما آن هذه 
الوحدات استلمت الواجهة القياسية التى تحدد فيها البيانات والوظائف الخاصة 
بهاء هذا بالاضافة إلى كونها قابلة للاستدعاء ككائن واحد كبير. بعد اكتمال هذا 
المشروع التجريبي» آثبت جدوى تجهيز نظم معالجة المعاملات عن طريق 
الإنثترنت حتى الكبيرة منها وتجهيزها للترحيل إلى بيثة عمل جديدة. كان الأداء 
معتمداً على ereطWebSp‏ لکن کان آداء النظام أقل من التطبيقات البنكية الأخرى 
التي تعمل من  PwebSphere Jil‏ , 


7-8 الاستنتاج 

حددت هذه المساهمة استراتيجيات لتزويد الهيكلية خدمية التوجه بخدمات 
الويب. كما أشرنا مسبقاً» یمکن شراء خدمات الويب أو استئجارها أو استعارتها 
أو تطویرها أو استعادتها. ثمة فوائد ومساوئ لکل ملهجية. أسرع وأرخص وسيلة 
لتزويد خدمات الويب» غير استعارتها من مجتمعات المصادر المفتوحة» هي 
استعادتها من التطبيقات الموجودة ضمن ملكية المستخدم. 

ثمَّة حاجة ملحة لإجراء المزيد من الأبحاث فى مجال استعادة الشيفرة 
البرمجية. أولاً هناك حاجة للتقنيات لتحديد الشيفرة البرمجية بثاءً على التتائج. 
ثانياًء يلزم الأمر وجود مقاييس لتقييم إمكانية إعادة استخدام الشيفرة البرمجية 
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المحددة. ثالثاً» يجب وجود أدوات لاستخراج سلاسل من مجموعات الشيفرة 
البرمجية المترابطةء آي خصائص الشيفرة البرمجية من البيثة التي تتواجد فيها 
تلك الشيفرة البرمجية. أخيراًء يجب توفر أدوات لتجهيز الشيفرة البرمجية 
المستخلصة أوتوماتيكياً وتكييفها كخدمة ويب. جميع هذه الخطوات عرضة 
للأتمتة؛ لكن لأتمتتهاء يجب التحقق من أكثر الوسائط موثوقية» وأفضاها لتنفيذ 
هذه المهام» كما يجب مقارنتها بالعديد من التقنيات. في هذا الصدد» يسهم 
الباحثون مساهمة قيّمة في عملية الترحيل. 
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9 
تحليل وتصؤر تطؤر البرمجيات 


(Michael Fisher) jı Jl 
(Harald Gall) Jİغ‎ دJIرlهg‎ 
(Marti Fizger) ومارتین پنزغیر‎ 


1-9 المقدمة 

يُعنى تحليل تطور البرمجيات بتحليل التغيرات التي تطرآ على البرمجية 
وأسباب التغيير وتأئيره. ويتضمن ذلك تحليلاً استرجاعياً للبياتات المُخرّنة فى 
مواقع التخزين الخاصة بالبرمجية. ۰ 

تتضمن تلك البيانات معلومات الإصدارات الماضية مع الشيفرة البرمجية 
المصدرية ومعلومات التغيير وبيانات الإبلاغ عن المشكلات والبيانات 
المستخلصة من تتبّع عمليات التنفيذ. تحديداًء» اكتسبث بيانات تحليل الإصدار 
والإبلاغ عن المشكلات أهمية نظراً إلى كونها تخزن ثروة من المعلومات القيّمة 
بالنسبة إلى تحليل تطور النظم البرمجية. 

آما تصور البرمجيات فهي وسيلة لدعم تحليل الجوانب المختلفة للنظام 
البرمجي بعروض رسومية. في هذا الفصل» نقدم أربع تقنيات تصور مختلقة مع 
التركيز على تصور جوانب نشوء البرمجيات. على وجه الخصوص» الجوانب 
المعنية بتطور وحدات الشيفرة البرمجية المصدرية (عرض مقاييس متعددة 
للتطور) وتطور الميزات (عرض تطور الميزات) ومساهمات المطوّر (عرض 
مساهمة المطوّر) وتقارن التخيير بين وحدات الشيفرة البرمجية المصدرية (عرض 
تقار التغيير). تتيح كل تقنية للمستخدم إنشاء عروض مختافة بهدف تسريعم 
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تحليل وفهم النظام قيد الدراسة. على سبيل المثال» تبن العروض هيكلية النظام 
كما تم تنفيذها مدعمة بمعلومات مقاييس التطور التي تلقي الضوء على 
النطاقات المهمة. تشير هذه النطاقات التي نسميها بالنقاط الساخنة إلى وحدات 
التنفي غير المستقرة وعيوب تنفيذ ميزات معيَّنة أو عيوب في تصميم وبناء 
الفريق. إن الإشارة إلى أوجه القصور هذه هي وسيلة لتحسين الثصميم والتنفيذ 
ومشاركة الفريق» وهذا هو هدفنا الأولي. 

مصدر البيانات الأساسية التي تستخدمها تقنيات التصور الأربعة المقدَّمة 
هي قاعدة بيانات الإصدارات السابقة ۸۴۲28 . تدمج قاعدة البيانات هذه 
الوقائع المستخلصة من إصدارات الشيفرة البرمجية العديدة وبيانتات الميزات 
والإصدارات (آي )٥۷8‏ وبيانات تتبع المشكلاث والعيوب (مثلاً عللن#عں8). 


Source 
Coda 


الشكل (1-9): عملية تحليل وتصور تطور البرججية مع خطوات امشخلاص 
البيانات (اليسار)ء وقاعدة بيانات الإصدارات السابقة وخطوة تنظيف البيانات 


(الوسط)ء ومنهجيات التصور (اليمين). 


D 


erne 


Viısualizalian 


Fac! Exlraction 


يبيّن الشكل 19 عرضاً عاماً لعملية تحليل وتصور تطور البرمجية. بين 
الجانب الأسر مصادر البياناث المختلفة»ء الث تؤخذ منها البيانات الأولية. 
حاليا» تستخدم العقنيات خاصتنا إصدارات عديدة للشيفرة المصدرية وتتيع 
التنفيذ؛ وإصدار البيانات من مواقع التخزين في ۳۷8؛ وبیانات الإبلاغ عن 
المشكلات من مواقع التخزبن في عللاعهں8. تخزن الوقائع المستخلصة من 
مصادر البيانات المختلفة في قاعدة بيانات الإصدارات السابقة. في خطوة تنظيف 
البيانات» يشم ربط وقائع مصادر الييانات المختلفة ما يتيح لنا التنقل بين 
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المشكلات إلى توصيفات الشيفرة البرمجية المصدرية المعدلة والميزات المتأثرة 
بالتغير والعكس صحیح. إضافة إلى ذلك نحن نراعي الإإصدارات العديدة 
ونؤسس الروابط بين الإصدارات للتنقل بين الإصدارات المختلفة لوحدة معينة. 

بعد ذلك» ولكل ملف مصدر نقوم بقياس حجم مقاييس التطور ومدى 
تعقيد البرنامج وعدد العيوب والمشكلات المبلغ عنها وعدد التعديلات التي 
أجريت وغير ذلك. أما بالنسبة إلى علاقات التبعيات بين الملفات المصدرية 
وقوة التبعية فیتم قياسها بحساب عدد مرات استدعاء العملية وعدد مرات 
الوصول للخاصية وعدد التسليمات المشتركة بين ملفين. تخزن البيانات الجديدة 
المحصلة في قاعدة بيانات الإصدارات السابقة» ومن هناك يمكن استرجاع 
البيانات باستخدام تقنيات التصور الخاصة بنا. 


9 2 عرض مقاييس التطور العديدة 
الشيفرة المصدرية. تصور هذه العروض الوحدات البرمجية وعلاقات التبعية ما 
بينها. تنبع الوحدات البرمجية من تحليل النظام إلى وحدات تنفيذية ذات معنى. مثل 
هذه الوحدات» هي عبارة عن فهارس للشيفرة المصدرية والملفات المصدرية 
والأنراع. تشير العلاقات التبعية إلى تبعيات الاستخدام أو توارث التبعيات. يرجع 
تفصيل تبعيات الاستخدام إلى العلاقات التبعية على مستوى الشيفرة المصدرية» 
تحديداً إلى تضمين الملف واستدعاءات العملية وصولاً إلى المتغير وثبعيات النوع. 

إن الهدف من عرض مقاييس التطور العديدة هو الإشارة إلى جرانب 
محددة من عملية تتفيذ إحدى إصدارات الشيفرة المركزية أو أكثر من إصدار - 
على سبيل المثال» وتسليط الضوء على الوحدات التي تحتبر كبيرة ومعقدة 
بشكل استثنائي» والتي تفرض علاقات تبعية قوية على وحدات أخرى. إضافة 
تزيدان بقوة أو الوحدات التي تصبح غير مستقرة. يمكن استخدام مثل هذه 
العروض من قبل مهندسي البرمجيات» مثلاً ل: 

(Î‏ الحصول على معلومات عن التصميم المتفذ وتطوره. 

ب) اكتشاف الوحدات المهمة التي تنفذ الوظائف الأساسية للنظام البرمجي. 

ت) اكتشاف الوحدات المقترنة بقوة. 
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ث) تحديد توجهات التطور الحرجة. 
آما الأفكار الرئيسة والمفاهيم الأساسية لعرض مقاييس الثطور العديدة فقد 
طورت في Pinzger JlaeÎ‏ والآخ .0ة , 


9 - 2 - 1 بيانات الشيفرة البرمجية المصدرية 

بالنسبة إلى عرض مقاييس التطور العديدة» تتكون بيانات الإدخال من 
معلومات الشيفرة البرمجية المصدرية المهيكلة وبياناث المقايس المستخلصة من 
عدد من إ[صدارات الشيفرة البرمجية. تحدد مقاييس الشيفرة المصدرية حجم 
ومدى تعقيد البرنامج كمياً وتقارن الوحدات وقوة العلاقات التبعية. إن مفياس 
حجم الوحدة المثالي هو عبارة عن عدد أسطر الشيفرة البرمجية وعدد العمليات 
وغدد الخصاثص وغير ذلك. أما مقاييس درجة تعقيد البرنامج فمنها على سبيل 
المثال درجة تعقيد ماكابي ءناھصەاعرC M۳4‏ ومحتری لاله الذكي» 
وجهد ل#عاءاها الذهني» وصعوبة برنامج ل#ماءا". تعطى قوة العلاقات 
الثبعية بعدد استدعاءاث العملية الثابثة أو الوصولية للخصائص بين وحدتين. 

إن استخلاص حساب العلاقات التبعية وغيم القياسات تنفذ باستخدام 
أدوات التحليل والمقابيس. في دراسات الحالة الخاصة بنا التي تجرى على 
برنامج لانعه ذي المصدر المفتوح؛ استخدمنا الأداة 42-×نعهم!" لحساب 
تحليل ومقاييس + 0/٥+‏ لمجموعة مختارة هن إصدارات الشيفرة المركزية. 
تخصص القيم القياسية لكل وحدة علاقة تبعية لمتجه إحدى الميزات. تم تتبع 
متجهات الميزات خلال عدد د من اللإصدارات وتكون مصفوفة التطور .۴٤‏ 
القيم في المصفوفة التي تحدد تطور الوحدة أو العلاقة التبعية كمياً: 


î MH Mî 

ٍ mM nM o. 
E I = 

mM mh mi 


تتضمن المصفوفة عدد ٦‏ من متجهاٽ المیزاٽ ذاٿت قياسات بمقاييس 1. 
<hftp: few imagix eom > (1)‏ „ 
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تحسب مقاپیس التطور لکل وحدة وکل علاقة تبعية. وهي تشکل مدخلا ساسا 
إلى منهجية التصور #ع اطع خاصتا, 


9 2 - 2 تصور قيم المقاييس المتعلدة لإحدى الإصدارات 


منهجية ا۷ھ هې امتداد لثقنية العروض ذاث المقاييس المتعددة 
المقدمة من لانرا ع#«و1 وآخرين". فيدلا من استخدام الأشكال الرسومية 
ذات العدد المحدود من المقايس القابلة للعرض» تسشخدم منهج Arch View‏ 
مخططات اهن الييانية المعروفة أيضاً بالمخططات الرادارية البيانية". هذه 
المخططات مناسبة لعرض قيم المقابيس المتعددة المتاحة للوحدة» كما ستييّن 
لاحقاً. 

بین الشکل 2-9 مثالا على مخطط K۲‏ بيائي يمثل قياسات ستة مقاييس هي 
هي M2 M1‏ ...ء M6‏ لإأحدى إصداراث تنفذ الرحدة شعلuلمص.,‏ الائات 
الضمنية في المخطط مأخوذة من مصفوفة التطور :٤‏ 


۳ 
î 
E. = 


mi; 

فی مخطط اہن الیانى ترتب قيم القياسات فى دائرة. ثمة ر 

ي تي رتب ميم في دائر هجو 
قياس في المخطط. حجم المخطط ثابت وكل قيمة تسوّى حسب المخطط. في 
الأمثلة الواردة في هذا القسم نستخدم معادلة التسوية الاتية : 

ım *ci 


—-— و 
(n) max( ıt )‏ 


حيث له تشير لأحجم مخططات انان والقيمة العظمى ٠ص)‏ ×و۳) هي 
أقصى قيمة لمقياس ” مستخدم في جميم الوحداث التي سيم تصورها. 

(#) طط الرادار اليا هر طريقة رسومية لعرض ييانات متعددة المتغيرات بصررة رسم بيان ني بعدين 
لثلائة متغيرات كمية أو أكثر ممللة على اور تيدأ من النقطة نفسها (الترجم). 
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موقع الرسم للنقطة على الخط. حتى تكون قيم القياسات مرثية على المخطط » يتم 
وصل قيم القياسات المتجاورة مشكلة بذلك مضلًعاًء» كالمبيّن في الشكل 29. 


M3 M2 
m 2 
mî 3 
mُ r 
ا‎ 1 Mı 
ns 
ms 
modtuieA 
M5 M6 


الشكل (2-9): حطّط انءاج للوحدة 4٥لuلهص‏ تمشل قراءات سثة مقاييس 
للشيفرة المصدرية 1» د5 M6 » » ٠ ١‏ للإصدار واحد 


مخططات ×4١‏ البيانية هي عبارة عن نقاط في المخطط البياني الذي 
يمشل الوحدات. يمكن أن تتصل هذه النقاط بحواف تشير إلى علاقات 
الاستخدام التبعية بين الوحدات. ترسم الحواف على شكل أقواس تشير إلى 
اتجاه العلاقة. 

يطبق مبدأ العروض ذات المقابيس المتعددة على الحواف أيضاً عن طريق 

بقة عدد العلاقات التبعية المضمنة ليكون عدد استدعاءات العملية الثابتة 

نفسها بين وحدتين بالنسبة إلى عرض القوس. 

هذا ويمكن تهيئة مجموعة المقاييس وترتيبها على المخطط. وينطبق الأمر 
ذاته على أنواع العلاقات التبعية والمقياس المطابق لعرض الاأقواس» وهذا يتيح 
للمستخدم إنشاء عروض مختلفة عن عمليات التنفيذ ملقياً الضوء على جوانب 
معيّنة. على سبيل المثال» يوضح الشكل 3-9 عرضاً لاأربعة محتويات ووحدات 
تصميم من إصدار 1.7 ولان#مM‏ . 
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4:LOC 4:LOC 


3:CYCL e Unie 
O:HALCONT O0 O:HALCONT 
2:HALDIFF 2:HALDIFF 
1HALEFF 1:HALEFF 
NowLayoMEnigine NoewHTMLStyloSystem 
#LOC 4:LOC 
3:CYCL 3:CYCL 


O:HALCONT 3 O:HALCONT 


2:HALDIFE Wf 2HALDIFF 


1:HALEFF 1'HALFFF 
XPToolkit 


الشكل (9- 3) : خطط ۷۲× بیانی لمحتویات موزیلا (00۷) ووحدات التصاميم 
NewLayoutEngine)‏ و NeyHTMLStyleSysterm‏ وXPo0Kit)‏ مبینا درج تعقید 


البرنامج وعدد أسطر الشيفرة البرمجية والمضمون القوي (الأقواس) للإصدار 1.7 


المظاهر المصورة في هذا الرسم البياني تعنى بتحديد الوحدات الكبيرة 
والمعقدة» إضافة إلى تلك التي تتضمن علاقات تبعية قوية في ما بينها. تعرض 
مخططات 4ن«ة× البيانية الوحدات الأريع والأفواس بينها تمثل العلاقات التبعية 
المضمنة. في مخططات ×4١‏ يمل حجم الوحدة بعدد أسطر الشيفرة البرمجية 
٣‏ وتمثل درجة تعقید البرنامج تمثل بمقاییس هولیستید H]۸1٤°0×1,(‏ 
HADIFF, (HALEFF‏ ومقياس ماكابي لدرجة التعقيد السيكلوماتي“. عرض 
الأقواس يمثل فوة العلاقات التبعية المضمنة» في حين يتم حساب عدد هذه 


DOM 


:MeCabe Cyelomatic Complerity (CCMPLX) («)‏ مقياس أو مؤشر مكاي أو مايعرف بدرجة 
التعقيد السيكلو ماني (ر ناوص عاام«ها»رت) هو مقياس أو قيمة يمكن من خلالها قياس درجة تعقيد برنامج 
أو خوارزمية معينة (الترجم). 
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العلاقات التي تقطع حدود الوحدة. هذا ويشار إلى الوحدات الكبيرة والمعقدة 
بمضلعات كبيرة. وتمثل العلاقات المضمنة القوية بأقواس سميكة. 


باستخدام طريقة الرسم هذه» يبيْن العرض بوضوح أن الوحدتين 
gai) (Document Object Model) DOM, NewLayoutEngine‏ فج كائن الوثيقة) 
هما وحدتان كبيرتان ومركبتان. وبالمقارنة بهماء يتضح أن الوحدة 
NewHTML]StyleSystem‏ هى وحدة صغيرة. كما يبيّن عرض الوحدة مدى قوة 
العلاقات بين الوحدات الأربعة. ما يشير الاهتمام هنا هو أن الوحدة 00M‏ التي 
تنفذ وظائف المحتوى تتضمن عدداً كبيراً من الملفات من الوحدتين 
NewLayoutEn gine‏ و NewHTMLeSystem‏ اللتین توفران وظائف تصميم 
صفحات الويب» وليس العكس»› كما كتا نتوقح. 

إضافة إلى ما تقدم» ثمة علاقة مضمنة قوية ذات اتجاهين بين الوحدتين 
ayoutEngineاNew‏ و .D0M‏ هذا ويجب مناقشة كافة جوانب القصور المحتملة 
مع المطؤرين لأنها تعيق تطوير وصيانة هذه الوحدات الثلاث. 


2-9 - 3 تصور قيم قياساث متعددة لإصدارات متعددة 


عند تصور قيم القياسات لعدد من الإصدارات المتتالية يكون تركيزنا 
الأساسي منصباً على تحديد التغير بين قيم القياسات. إن الزيادة في القيم تشير 
إلى وجود إضافة وظائف» بينما يشير النقص في القيم إلى حذف من الوظائف. 
إضافة الوظائف هي إشارة عادة إلى تطور النظم البرمجيةء فهي إذاً لا تشير إلى 
وجود مشكلة. على العكس من ذلك فإن حذف وظائف يشير إلى تغير في 
التصميم. على سبيل المثالء نقل العمليات إلى نوع (ه1٥)‏ مختلف لحل 
العلاقة التبعية ذات الاتجاهين أو حذف عمليات بسبب حذف شيفرة برمجية لم 
تعد مستعملة. 


لإلقاء الضوء على التغيير في قيم القياسات» نستخدم مخططات اKivia‏ 
البيانية» كما ورد سابقاً. يتم الحصول على القيم ” لكل مقياس من الإصدارات 
المتعددة» ویتم رسمها على نفس المحور. يتم وصل قیم القياسات المتجاورة 
بخط لتشكل مضلعاً لكل إصدار. يتم ملء المنطقة الناتجة بين مضلعين 
لإصدارين متتاليين بآلوان مختلفة. يشير كل لون للتغيرات بين قيم قياسات 
إصدارین. كلما كان حجم التغيير كبيرآ زاد حجم المضلع. 
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يبن الشكل 49 وحدات موزيلا الأربع نفسها كما كانت سابقاً» لكن هذه 
المرة بوجود بيانات المقاييس لثلائة إصدارات متتالية هي 0.92 و1.34 و1.7. 
تشير المضلعات ذات اللون الرمادي الفاتح إلى التغيرات بين الإصدارين 1.34 
و1.7. 

بين العرض تغيرات قوية في الو -حدتيù DOM‏ وNewHTMLStyleSysteı‏ . 
في الوحدة الثانية +« قلت فيم قياساٽت هتيد ù HALDIFFy HALCONT‏ 
الإصدار السابق والإصدار الأخير بشكل ملحوظ» على الرغم من أن الحجم 
(عدد أسطر الشيفرة البرمجية) لم يتغير كثيراً. من الواضح أن الشيفرة المصدرية 
لهاتين الوحدتين قد أعيد تصميمها. 


4:LOC 


3:CYCL è> 3:6YeL 


O:HALCONT # ے‎ 0:HALCONT 


2:HALDIFF 2:HALDIFF 


1:HALEFF THALEFF 
NewLayoutEngine NewHTMLStyleSystem 


41l06 


3:CYOL 


O:HALCONT 
è 0:HALCONT 


2:HALDIFF 


1HALEFF 
XPTooikit 


الشكل (9- 4): مخطط ×۷١‏ لمحتويات علان#ه ونماذج العرض الني تبي درجة 
تعقد البرنامج ومقاييس عدد أسطر الشيفرة البرمجية وكثافة ثلاثة إصدارات فرعية 
مثعاقبة 0.92 و1.3 و1.7. 
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زادت قيم القياسات لوحدة 00۷ في البدايةء ثم قلت في الإصدار الأخير 
مرة أخرى. أولاً أضيفت الوظائف إلى الوحدة التى أعيد تصميمها فى أثناء ثنفيذ 
الإصدار الأخير. بمقارنة هاتين الوحدتين» تشير قيم القياسات للوحدات الأخرى 
تغيراً طفيفاً في الحجم ودرجة تعقد البرنامج؛ ما يعني ثباتها. بناء على افتراض أن 
الوحدات التى تغيّرت فى الإصدار السابق ستتغير فى الإصدارات المستقبلية فإن 
الوحدتين DOM‏ و NewHTMLStyleSystem,‏ مر شحتان للتغير ما يعنى ضرورة 
الاعتناء بهما. ٠‏ 


يبيّن الشكل 49 مخطط اها«ن البيانى لأربعة من محتويات موزيلا 
ووحدات التصميم مبيّناً درجة تعقيد البرنامج وعدد أسطر الشيفرة البرمجية 
والمضمون القوي (الأقواس) لثلاثة إصدارات متتالية هي 0.92 وه1.3 و1.7. 


9 - 3 عرض تطؤر ميزات النظام البرمجي 

الميزات هي طريقة لعرض النظم البرمجية من وجهة نظر المستخدم. فكما 
يشير كانغ ع«ةK‏ وآخرون"» الميزة هي مظهر بارز أو مميز أو جودة أو سمة 
من سمات النظام أو النظم البرمجية. بما أن الميزات تستخدم في التواصل بين 
المستخدمين والمطرّرين فمن الأهمية بمكان معرفة الميزات التي تتأثر بالتعديلات 
الوظيفية في النظام. تركز تقنية تصور الميزة المقدمة في هذا القسم على إنشاء 
غروض ذات مستوى متقدم للميزات وتطبيقها في الشيفرة البرمجية المصدرية› 
إضافة إلى تبعياتها حسب تعديلات وأخطاء النظام. آما الأفكار الرئيسة ومفاهيم 
عروض تطور الميزة فقد طرّرت في أبحاث فیشر ۲٥۲ء۴‏ والهع“ . 


9- 1-3 بيانات الميزات والتعديلات وأخطاء النظام 


تنتقى بيانات الإدخال للتصور من قاعدة بيانات الإصدارات السابقة. تحصل 
تقارير التعديلات من تظم الإصدارات ك ۷8©. فهي تتضمن معلومات عن من 
آجری التعديل»› وأي ملف مصدري معدل» ومتیى ت ذلك. آما تقارير أخطاء 
النظام فيتم الحصول عليها من نظم تتبع الأخطاء كنظام 11و8 . فهي من بين 
التقارير الأخرى تتضمن معلومات عن تاريخ الإبلاغ عن الخطاً والمكزّنات 
المتأثرة به ووصف مختصر للمشكلة وأولويتها ودرجة خطورتها وملاحظات عن 
الإصدارات الصغيرة التي ستتضمن حلولا لها. 

آما في ما يتعلق باستخلاص بيانات الميزة» فنحن نستخدم تقنية استطلاع 
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البرمجية التي قدمیا کل من 0 Wilde‏ وسکالي وا6 . ت نثفذ ا 
باستخدام أداة إعداد ملفات ا (مثان „(GNU gprof‏ و بع آثر 
التنفيذ تسلسل الوظائف (أي رسم بياني للاستدعاء) المنفذة في كل 8 لکل 
الملفات المصدرية ويتم تعيينها للمفاهيم التي تمثل الميزات. ئم يتم تخزین 
مجموعة الوظائف والملفات المصدرية التي تنفد ميزة معيّنة في قاعدة بيانات 
الإصدارات السابقة. 


یتم ربط تقارير التعديلات وبيانات الميزة بواسطة ملفات مصدرية. يتم 
توفير ربط بيانات ملف التعديلات وملف الأخطاء إما بواسطة نظام الإصدارات 
أو نظام تتبع الأخطاء أو قد يتم إعادة بنائه. بالنسبة إلى نظام الإصدارات ٣۷8‏ 
ونظام تتبع الأخطاء ماانععد8 فهي الحالة الأخيرة. يتم إعادة بناء الروابط عن 
طريق الاستعلام عن وصف التعديل (آي ملاحظات الاعتماد" في ۷8ع) 
للإشارة إلى تقارير الأخطاء (#2345 عuط .(e.g.,‏ عندما یتم العثور على هله 
الإشارة يتم تخزين رابط بين التعديل وتقرير الخطأً المرتبط به في قاعدة بيانات 
الإصدارات السابقة. لمزيد من التفاصيل حول استخلاص بيانات الميزة 
وخوارزمیات تکامل البیانات»› یرجی مطالعة عمال e۲ط۴isce‏ وآخری 5 , 


2-3-9 عرض المشروع - إبراز تقارير الأخطاء على هيكلية الفهرس 


يصور عرض المشروع تنفيذ الميزات بواسطة الملفات المصدرية وتقارنها 
من خلال تقارير الأخطاء باستخدام الرسم البياني. تمشل النقاط فهارس 
الشيفرة البرمجية المصدرية» تشير الحواف المتقطعة ذات اللون الرمادي إلى 
تسلسل الفهرس الهرمي (شجرة المشروع). تمثل الميزات بمستطيلات مرفقة 
بنقاط الفهرس وتحتوي على الملفات ت المصدرية التى تنفذها. أما الأقواس 


الرمادية المتصلة في لر لاني ف فتشير إلى التقارن بين الميزات من خلال 
میزات موزیللا. 


(8) الاعتماد (انسسهت) في هذا السياق يعني تحويل مجموعة من التغيرات المحتملة إلى تغيرات دائمة 
(المترجم). 
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| @ Htmı 


الشكل (9- 5): علاقات الربط والتطبيق لبنية موز« «Hittps «Mozilla Ffttp‏ 
ا من خلال تقاریر خط 


شكلياً» تكون النقطتان ا« وزه في الرسم البياني متصلتين إذا كان فهرسان 
اثنان بحتويان ملفات مصدرية تتشارك في تقرير خطا (أي ملفات تم تعديلها 
لإصلاح الخطا). يتم احتساب أوزان الحواف بين النقاط باستخدام المعادلة 
الآتية» حيث إن د تحدد عدد الارتباطات الحالية بين النقطتين ويرم هو العدد 
الأقصى للارتباطات (العامة) بين أي نقطتين في الرسم البياني : 


k 
weight (vj, vj) = (1) ( 4 ) + 0 


FHmax 
0 عندما تكون 1=ه» فإن جميع الأوزان تُعيّن للمدى [0... 1]» حيث‎ 
يعني أقرب مسافة (ع تحكم المسافة الناتجة بين النقاط وثيقة الصلة). في الرسم‎ 
البياني الناتج» أما الخطوط السميكة الأغمق لوناً فتعني أن عدد تقارير الأخطاء‎ 
التابعة المشتركة بين نقطتين كبير. نستخدم الأداة ابع ×۳ لتصميم الرسم‎ 
البياني (وهي تطبق خوارزمية التحجيم متعدد الأبعاد).‎ 
من الخطوات الحاسمة في عملية إنشاء الرسم البياني خطوة اختيار معابير‎ 
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الأوزانء ذلك آن لها تأثيراً مباشراً في التصميم النهائي. استخدمنا النسبة 20:1 
لحواف الشجرة وحواف تقرير الأخطاء. هذا المخطط يعطي تركيزاً على هيكلية 
الفهرس أكثر من الارتباطات التي يعرفها تقرير الخطاً. في الخطوة الأولى من عملية 
إنشاء البيانات» يتم تعيين كوائن شجرة الفهرس للنقاط الخاصة بها على الرسم 
البياني. یحدد آدنی حجم لفرع في الشجرة (4انطعمنص) النقاط الموسعة (أي التي 
تبدو فروعها) أو تلك التي سيتم طيّها (آي إخفاء فروعها). الطي يعني أن الكوائن 
التابعة للشرعة الفرعية ستنقل إلى المستوى الأعلى الأقرب إلى أن يتحقق معيار 
الحجم» لكن الانتقال لا يتجاوز أول مستوى تحت النقطة الجذرية (علهد ۸001). 
الفهارس غير المؤشرة يتم إخراجها. في الخطوة الثانية» يكون من الممكن نقل نقاط 
ذات مؤشر أقل إلى مستوى أعلى للحصول على تمثيل أكثر تراصاً. أما التأثير في 
الرسم البياني فهو أن الأطراف غير المؤشرة يتم منعهاء على الرغم من أنها تحوي ما 
يكفي من الكوائن لتحقيق معيار الفرع الأدنى فانطهعنط. وهذا يقل كمية 
المعلومات التي سيتم تصورها أكثر ما يحسن من فهم الرسوم البيانية الناتجة. 

في الأقسام الفرعية الآتية نبيّن مثالين لعروض المشروع» كما تم إنشاؤها 
في دراسة حالة خاصة بمشروع ماان#ه« ذي المصدر المقتوح. 


9- 3-3 تقارن تقرير الخطاً ہین خصائص : Hinlg Hips Mozilla Ftp‏ 


الخصائص الثلاث م))۴ ووما)#۴ واصا۴1 موضحة في الشكل 59. اخترنا 
جميع تقارير الأخطاء كبيانات إدخال لهذه الخصائص باستفناء التقارير المصنفة 
ك «تحسينات» منذ بداية المشروع حتى تاريخ التوقف في 10 كانون الأول/ 
ديسمبر 2002. لأغراض التصور»ء قمنا بتهيئة الخوارزمية باعتبار أن القرع الأدنى 
minchild‏ = 1 (آي عدد الملفات في الفرع الأدنى) وباعتبار أن التراص = 1 


(أي عدد تقارير الأخطاء المؤشر عليها من قبل النقطة). 

بالنسبة إلى عملية التسوية» قمنا بوزن أطراف شجرة المشروع ب 20» 
العوامل التالية لمعادلة الوزن للتشديد على الانتشار بين النقاط لأغراض 
التصور: k‏ = 0.2 وه = 0.2. 

كمية تقارير الأخطاء الإجمالية التي يتم الكشف عنها عند نقطة واحدة 
يشار إليها من خلال قطر النقطة» أما الميزات المستضافة من قبل النقطة وتكون 
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مرفقة على هيئة صناديق. من السهل إدراك وضع النقاط التي تنتمي إلى خاصية 
اا۴ في الطرف الأيمن في الشكل 5-9 وخاصيتي «))۴ وهم))۴ في الطرف 
الأيسر . security/manager/ssl ş network/protocol/http 9 network/base bill‏ 
هى نقاط مهمة» وذلك أنها متقارنة من خلال 90 تقريراً من تقارير أخطاء 
الطرف مااط-عوهطء و40 تقريراً من تقارير أخطاء الطرفين الآخرين. وهذا يشير 
إلى وجود درجة عالية من التقارن بين الخاصيتين Httpsg Http‏ . 
من الجوانب الأخرى المهمة انتشار خاصية اصا۴ خلال 10 نقاط مختلفة. 
قد يصعب تتبع التعديلات لوجود العديد من الملفات في الفهارس المختلفة 
التي تشترك في ميزة واحدة. ما النقطتùl l4 layout/html/baseg content/base‏ 
الرغم من وجود أربعة ملفات في فهارس النقطة الأولىء وثلائة ملفات في 
فهارس النقطة الثائية فقط. 
نتيجة لذلك» يبيّن الشكل 5-9 تبعيات تغيير قوية للخصائص المعنية خلال 
القهارس المختلفة» ويشير أيضاً إلى تدهور الهيكلية نتيجة تطور البيانات : 
1. فد تشیر الخصائص المنتشرة في شجرة المشروع إلى تطور كمية كبيرة 
من الشيفرة البرمجية الأساسيةء وبالتالي فإن تأئير التغيير يكون كبيراً. 
2. قد تشير التبعيات بين فروع شجرة المشروع إلى وجود تبعيات أخری 
کالاستدعاء أو الوصولية آو التوارث أو الارتباط. 
3. الأخطاء التي يتم الإبلاغ عنها بشكل متكرر المتعلقة بالشيفرة البرمجية 
المصدرية لمواقع الخصائص قد تكون مؤشراً على مشكلات في التنفيذ 
آو التصميم. 
9- 3 - 4 تقارير الأخطاء المتقارنة بين خصائص وأسأسات aاانMo7‏ 
يبيّن الشكل 9- 6 الخاصية الأساسية (ملفات مصدرية غامضة قابلة 
(الأطراف التي تمثل أآقل من خمسة مؤشرات يتم حذفها). للحصول على هذه 
التهيئة قمنا باختيار جميع التقارير المصنفة «رئيسة» أو #حرجة). كما قمنا بتحديد 
أدنى حجم للشجرة الفرعية ب 250 (كائنا) (أدنى أطراف) وأدنى عدد لمؤشرات 
الفروع ب 50 (متراص). نتج من ذلك مخطط بياني ذو 37 نقطة و 315 طرفاً ناجمة 
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عن تقارير الأخطاء. بتغير قيم الأطراف الدنيا والتراص» يصبح من الممكن إنشاء 
مخطط بياني تفصيلي تعسفياً للمشروع كاملا. بما إن موزيللا تتضمن أكثر من 
0 فهرس فرعي» يكون من الصعب الحصول على مخطط بياني يمثل شجرة 
المشروع كاملة نظراً إلى إمكانيات التوضيح المحدودة. من البدهي أن ترتبط 
معظم النظم الفرعية في موزيلا في التصوّر وقد دعمت نتائجنا هذا. 

النقاط الأعلى كثافة في تقارير الأخطاء المصنفة على أنها الرئيسة 
والحاسمة هي content‏ )608 مؤش( layout/xulg (444) layout/htmly‏ )223( 
وامرها (212). من الجوانب الأخرى المهمة انتشار الأطراف. لذاء فإن 
إجمالي عدد الارتباطات الموصوفة بين النقاط يكون 343. فإذا اخترنا الأطراف 
التي تمثل 10 مؤشرات فحسب فإننا نستطيع إيجاد الرتب الآتية : أصعاصهه ب 19 
طرفاً واا ط/اouرھا‏ ب 10 أطراف ولاعوعمل ب 9 أطراف وصهل ب 5 أطراف 
layout/xulhasey‏ وnetwork‏ وuriloader‏ ب 4 أطراف لكل منها. في المجموع»› 
تتشارك 23 نقطة الأطراف مع نقاط أخرى بعشرة مؤشرات على الأقل» لكن 19 
نقطة منها ترتبط بالنقطة اصعاصهء. وهذا يؤكد الموقع الاستثنائي للمحتوى الذي 
يشار إليه بست خصائص مختلفة موجودة هناك. 
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الشكل (9- 6): العلاقة الوظيفية بين بنى ولاء7٥»‏ وبنى eاo٣‏ 
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نتيجة لذلك» تتيح الصور كالشكل 9- 6 للمحللين رسم الاستنتاجات الآتية : 


1. تظهر النقاط ذات التغيير المتكرر بحجم أكبر من النقاط الأخرى ويمكن 
رصدها بسهولة. 


2. الأجزاء غير المستقرة من النظام كالمحتوى يكون موقعها بالقرب من 
مركز المخطط البيانى وتكون شديدة التقارن بالنقاط الأخرى. 


3. الميزات ذات الشيفرة البرمجية المشتركة ثرفق بتقاط محددة وتكون 
قريبة من بعضها البعض (مثال ذٺلك (XML, MathMI‏ . 


4. مجموعات ميزات محددة (مثال» ميزة الصور) المنتشرة عبر نقاط عديدة 
يمكن رصدها بسهولة (مثاJ‏ « illقlط (contentg layout/htmlg modules, jpeg‏ , 
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كتتيجة لذلك» المواقع ذات التغيير المكثف وانتشار الميزات تشيران إلى 
أجزاء البرمجية التي يجب آن تراعى لإجراء مزيد من التحقق من حيث الحد من 
التعقيد الكبير أو تدهور الهيكلية. 


9 4 عرض إسهامات المطؤرين 

في هذا القسم» نركز على تصور الجهود التي بذلها المطورون لتصحيح 
الأخطاء وتطوير النظم البرمجية. إن الهدف الأساسي لعماية التصور هذه هو توفير 
رۋى عن عدد المرات التي تخيرت فيها وحدة الشيفرة البرمجية المصدرية ومن 
أجرى تلك التغيرات. تبيّن العروض الناتجة أنماطاً تمكننا من التفكير في سلوك 
التغير لوحدات الشيفرة البرمجية المصدرية» كما لو أن هناك مطرراً مركزياً أو 
عدة مطؤرين يجرون هذه التغيرات. الأفكار والمفاهيم الأساسية لعروض الكسور 
ieW(‏ ۴) طورت من خلال اعمال دامبروس ٥۲ص24‏ وآخری . 


9- 4 - 1 بيانات التعديل 
كما في المنهجية السابقة» نحصل على تقارير التعديلات من قاعدة بيانات 


الإإصدارات السابقة ۸۸128 ونقوم بحساب عدد الاعتمادات لكل مؤلف وملف 


مصدري. على سبيل المثال» يبيّن الجدول 1-9 المطؤرين الذين عملوا على 
الملف المصدري صمء.إءمآء۲۴×١١ءم‏ الخاص بموزيللا وعدد الاعتمادات التي 


تقذها كل منها. 
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العدول (9- 1) 
المؤلفون وعدد الاعتمادات التي تفدوها على املف الملصدري 
ns extHelper.cpp‏ الخاص بمو زیللا 


المؤلف غدد الاعتمادات 


ر 


warren{Ênetscape.cOm 
gerv(dyerv.net 
dconednetscape.con 
dbaront{Ofas.harvard.edu 
cltbidé@netscape.conı 
PierreOnetscape.com 
dmose(@mozilla.orgy 
jusgernaut@netscape.con1 


8 مطورون 4 اعتماد 


لا لإ سے نسل س س س 


الحقرق غر طة 188۴ 2005 © 


تصور العروض الكسيرية (1هاآ ۴۵ «ء۷)"“ جهود التطوير التي بذلها كل 
مؤلف في العمل على وحدات الشيفرة البرمجية المصدرية. لهذا العرض» تشير 
وحدات الشيفرة المصدرية إلى الملفاث المصدرية. تمشل كل وحدة يشكل 
المستطيلات المملوءة ذات أحجام وألوان مختلفة. يعين كل مستطيل (وبالتالي 
كل لون) لمؤلف يعمل على الملف. وباستخدام مبداً مطابقة القياس» تتناسب 
مساحة المستطيل مم نسبة جهود التطوير المبذولة من قبل المؤلف من إجمالي 
الجهد. وبالتالي فإنه كلما زاد الجهد الذي ييذله المطوّر في العمل على وحدة 


(#) پمکن تعريف الکسيرية على آنا كائن هندسي خشن غير متتظم على كافة المستويات» ويمكن تثيلها 
بعملية كسر شيء ما إلى أجزاء أصخرء لن هله الأجزاء تشابه الجسم الأاصل. حمل الكسيرية في طياتها ملامح 
مفهوم اللابابةء وتتميز بخاصية التشابه الذانيء آي إن مكوناتا مشابهة للكسيربة الآم مهما كانت درجة 
التكبير. غالبا ما بتم تشكيل الاجسام الكسيرية عن طريق عمليات آو خوارزميات متكررة: مثل العمليات 
التراجعية (eبامسبصه‏ آو التكرارية (مبنوعا!) (الحرجم). 
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معيّنة» كان المستطيل الذي بمثله أكبر. بعطى الجهد كعدد الاعتمادات لكنه 
ليس محصوراً بالعدد. يمكن أيضاً استخدام مقاييس أخرى كعدد أسطر الشيفرة 
البرمجية المضافة أو المحذوفة. 

المثال التالي المبين في الشكل 7-9 والخاص بالملف وصns1extEelper.op‏ 
يشرح عملية بناء عروض الكسور. أخذت البيانات من الجدول 1-9. 

المستطيل الأول ذو اللون الرمادي الغامق في الطرف الأيسر يمثل المؤلف 
الذي أجرى أكبر عدد من الاعتمادات وه„ warrene@netscape.corm gî‏ . 
مساحة المستطيل هي 14/5 من إجمالي المساحة ذلك أن عدد الاعتمادات التي 
نفذها هذا المؤلف هو 5 بينما العدد الإجمالي هو 14. رسمت المستطيلات 
الأخرى بالطريقة نفسها مع تغيير اتجاه الجانب الأطول كل مرة. 

پتغیر اتجاه الرسم لتحسين التدرج في تقنية التصور. حئی عندمها يکون 
هناك مثات المؤلفين ستبيّن الأشكال الكسيرية أن التطوير مجزأً بصورة كبيرة. 


TT TT T8 


lê com dcoeccnetscape.com gerv@pgery 2 
Empty Fractal Direction Direction =p Direction Complete Feactat 
Figure او‎ Area = 2/14 e ا‎ 


Sire metre 


الشكل (7-9): مبدآإنشاء الأشكال الكسيرية ملف علان#ه» المصدري 
nsTextHelper‏ 


الحقوق نو ظط 188۴ 2005 © 


9- 4 - 3 تصنيف الملفات المصدرية مع العروض الكسيرية 

تستخدم العروض الكسيرية للتحقق من جهود تطوير الكوائن من وجهة 
نظر المؤلفين. يمكننا مقارنة الكوائن بالنظر إلى أشكالها وتصنيفها حسب 
أنماط التطوير. يإمكاننا التمييز بين أربعة أنماط تطوير رثيسة» كما هو مبين في 
الشكل 89: بوجود مطرّر واحد فقط (أ)» بوجود بعض المطورّرين والجهد 
متوازن (ب)» بوجود عدد كبير من المطورين لكن الجهد غير متوازن - 
أحدهم يقوم بنصف العمل والباقون يقومون بأداء النصف الآخر (ج)» وبوجود 
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العديد من المطرّرين الذين ينجزون مقدار العمل نفسه تقريباً (د). 

يمكن أن تستخدم العروض الكسيرية أيضاً عندما تكون وحدات الشيفرة 
البرمجية ذات مستوى متقدم كفهارس الشيفرة البرمجية المصدرية. لهذا الغرض› 
يتم تجميع مقاييس الكوائن المحتواة (أي الملفات المصدرية). على سبيل 
المثال» عدد إصدارات الفهرس هو مجموع أعداد إصدارات الملفات المصدرية 
المحتواة. إضافة إلى ذلك» توسع التعبير عن العروض الكسيرية بواسطة مقاييس 
المطابقة لتشمل حجم المستطيلات. وهذا پسمح لنا تصنيف هذه الكوائن ذات 
المستوى المتقدم من حيث جهود التطوير وتوزيعه. 


LE 


(8) One developer {b] Few balanced developers 


{€} One major and many minor developers {O} Mony halanced develapers 


الشكل (9- 8): أنماط التطوير بناء على آشكال غيشتالت (٤1ماءء6)‏ والأشكال 
الكسيرية(* 


الحقوق غنوظة 188۴ 2005 © 
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على سبيل المثال» يبيّن الشكل 9-9 التسلسل الهرمي للفهرس ااعطواءس 
التابع لموزيللا. تمثل الأشكال الكسيرية الفهارس التي تتضمن ملفا مصدرياً 
واحداً على الأقل»؛ بينما ترتبط الأشكال رمادية اللون مع الفهارس الحاوية - 
بمعنى أنها الفهارس التي تحتوي على فهارس فرعية فقط. نستخدم عدد الملفات 
كمقياس للحجم. الشكل المرقم ب 1 يمثل أكبر فهرس - أي هو الفهرس الذي 
من التطوير - جهد متوازن». 

إن مجموعة الأشكال المرقمة ب 2 تميّز بما يآتي : 

(1) الأشكال التي تنتمي إلى الهيكل الهرمي لفسه. 

)2( تعرضصس مطوّراً واحداً أو مطوْراً رئیا واحداً. 

(3) بعض الفهارس يتضمن عدداً كبيراً جداً من الملفات. 

ثمة مثال آخر مأخوذ من دراسة حالة موزيللا معطى في المثال 10-9. 
العرض الكسيري يوجد في الفهرس لصاط/٣هانلءطنا/ءه‏ اله . الأشكال الكسيرية 
تمثل الملفات المصدرية (على الجانب الأيسر) والفهارس (الزاوية اليمنى 
العليا). نستخدم عدداً من الإصدارات لأحجام المستطيلات. 

م علدا من ا f‏ 

الأشكال المستطيلة التي تمثل الملفات المصدرية تشير إلى ملف واحد 
(المرقم ب 1) وهو أكثر الملفات تعديلاً من قبل عدة مطررين. يشير نمط 
التطوير لهذا الملف إلى وجود عدد من المتطورين بجهد متوازن. أما 
المستطيلات المرقمة ب 2 فهي أيضاً مهمة لأنها تظهر سلوك التغيير نفسه. من 
المرجح أن تكون متقارنة من حيث التغيير (آي إنه في الأغلب ما يتم تعديلها 
معاً) لأن: 

1) لها نمط البرمجة نفسه ومظهراً متشابهاً. 

يعكس الشكل الكسيري الذي يمثل الفهرس أنماط الملفات المصدرية 
المضمنة: هناك العديد من المطررين الذين يعملوك بتوازث لكن المساهمة 
الأعظم تأتي من مطوّرين اثنين وبعض المطوّرين الآخرين المخادعين. 
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الشكل (10-9): توزع المظهر لنظام )editor/libeditor /htrml directory)‏ في 
y1 <‏ 
موزیللا 
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5-9 عرض ثقارن التغيير 

يحدث تقارن التغيير عندما يُجرى تغير على وحدتين برمجيتين أو أكثر من 
قبل المؤلف نفسه وفي الوقت نفسه»ء تقريباً. في هذا القسم» نقدم تقنية 
ع التصورية التي تركز على إلقاء الضوء على تقارن التغيير بين الملفات 
المصدرية والوحدات البرمجية. تشير الوحدات البرمجية إلى الفهارس في شجرة 
المشروع. ظهرت الأفكار والمفاهيم الرئيسة لعروض تقارن التغيير وطورت في 


OD, «7T 


أعمال راتزنغر ۲٥عم‌اعاه۸‏ واخرین 
إن هدف عروض تقارن التغيير هو تحديد الملفات المصدرية والوحدات 
التي تتغير مع بعضها البعض في معظم الأحيان. يمكن أن تستخدم هذه المعرفة؛ 


التغيير (مثلاً عند تغيير هذه الوحدة فإن وحدات آخری یجب أن تتغير). 
9- 5 - 1 بيانات تقارن التغبير 


يتم الحصول على بيانات عروض تقارن التغيير من قاعدة بيانات 
اللإصدارات السابقة. فهي تضم معلومات فهرس الشيفرة البرمجية المصدرية 
وعدد الاعتمادات لكل ملف مصدري وعلاقات تقارن التغيير بين الملفات. 
حالياًء بنيت قاعدة البيانات من بيانات .٤۷8‏ نظراً إلى أن C۷8‏ لا يدعم 
عمليات الاعتماد انصسصه»» يجب أن يعاد بناء علاقات تقارن التغيير بين 
الملفات المصدرية. نستخدم معلومات المؤلف والبيانات ومعلومات رسالة 
الاعتماد لإعادة بناء هذه العلاقات. بشكل أساسى» فإن تقارير التعديلات التى 
يجريها المؤلف نفسه في رسالة اعتماد واحدة واعتماد الوقت نفسه ١ا‏ تُجمع 
في حركة واحدة. يتم تأسيس علاقات تقارن التغيير بين كل مجموعة من هذه 
المجموعات وتخزن في قاعدة بيانات اللإإصدارات السابقة. 


9 5 2 عروض Evo]‏ 
منهجية ٤۴۷٥1٤8‏ هى تقنية تصور تفاعلية قائمة على المخططات الرسومية 
تمثل هيكلية الفهرس والملفات المصدرية كمخطط رسومي متداخل. يتم تمثيل 
الملفات المصدرية بشكل إهليلجي» ويتم إحاطة الفهارس بمستطيلات. أما تبعيات 

ثقارن التغيير بين الملفات المصدرية فتمتل على شكل خطوط مستقيمة بين العقد. 
تتبع منهجية £۷01٥8‏ مبدأً مطابقة المقاييس الموضح مسبقاً. بالنسبة إلى 
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الملفات المصدرية» يتم مطابقة معدل النمو في عدد أسطر الشيفرة البرمجية 
المضافة أو المحذوفة مع ألوان النقاط في الشجرة. أساسياًء اللون الخفيف يشير 
إلى نمو أدنى واللون الكثيف يشير إلى نمو أقصى. أما في ما يتعلق بمقارنة 
التغيير فيتم مطابقة عدد الاعتمادات المشتركة بين ملفين مع عرض الأقراس؛ 
فكلما كان عدد الاعتمادات المشتركة بين ملفين مصدريين أكبر» كان عرض 
التصور المختلفة مع أمثلة مأخوذة من دراسة حالة خاصة بنظام أرشفة الصور. 


9- 5 - 3 التصور الرسومي المتداخل 


عند تحليل نظام برمجي كبير» ينصح باتباع منهجية #التحليل من الأعلى 
إلى الأسفل» التي تبدأً من الصورة التفصيلية. تتبع منهجية 8ء8۷01 منهجية 
التحليل من الأعلى إلى الأسفل باستخدام الرسوم المتداخلة. يتم تصور 
الوحدات عند المستوى العلوي» أما الوحدات الفرعية فيتم تصورها في 
المستوى التالي يتبعها الملقات المصدرية الني يتم تصورها عند المستوى 
الأدنى. تستخدم النقطة المركزية (البؤرة) لتركيز التحليل على علاقات تقارن 
التغيير لكيان معيّن. أما التوصيفات غير المتقارنة من حيث التغيير مع توصيف 
آخر فتهمل› وهذا ينتج مخططات أبسط وأسهل فهماً. النقطة المركزية معدة من 
قبل المستخدم ليتم التركيز دائماً على التوصيف موضع الاهتمام. يوضح الشكل 
9 مثالا على عرض تطور يبن تقارنات التغيير بين الوحدة الرئيسة والوحدات 
الفرعية مع النقطة المركزية في الوحدة «0نواهز. 

یتم رسم النقاط كمستطيلات وتمثل الوحدات الرئيسة والوحدات الفرعية. 
يتم التعبير عن تداخل الوحدات الرئيسة والوحدات الفرعية بواسطة النقاط 
المتداخلة. على سبيل المثال» تبيّن النقطة التي تقع في المركز أن الوحدة 
«ەنواہز تتكون من 10 وحدات فرعية. 

في منهجية 8« 01ہ8» يتم رسم العلاقات الداخلية وعلاقات التقارن بين 
الوحدات الداخلية. يشير عرض الخط إلى قرة التقارن من حيث عدد الاعتمادات 
المشتركة. عند مستوى الوحدة والوحدة الفرعية» يكون هذا العدد عبارة عن 
مجموع تقارنات التغيير الرئيسة بين الملفات المصدرية لأزواج الوحدات. 
المخطط الرسومي في الشكل 11-9 يشير إلى تقارنات التغيير بين الوحدات 
الفرعية التابعة للوحدة #هاون«ز. في هذه الوحدة» تتغير كل من #عهص؛ ومنةص 
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visy overlayy renderery‏ کثیراً مع بعضها البعض» كما هو مين بالخطوط 
السميكة المرسومة بين نقاط المخطط المترابطة. أما الوحدة الفرعية نةه 
فتسبب تقارن الوحدات الداخلية مع علاهاز» وعليه فإن هناك مرشحاً أولياً 
لتغيير تصميم البرنامج من دون التأثير في النتائح ع٣٣‏ 0اc re]‏ . 


chkelassijfolde 


الشكل (9- 11): خطط متداخل لتصور الوحدة "م0 نونز 
الحقوق فر ظة 18۴۴ 2005 © 


بمكن إجراء التكبير والتصغير في المخطط الرسومي عن طريق توسيع أو 
َي نقاط الوحدة أو الوحدة الفرعية. إضافة إلى آلية التكبير/ التصغير التقليدية» 
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توفر منهجية 8«ءاه»ع آلية فلترة ذات عتبات قابلة للتهيئة. وهذا يسمح 
للمُستخدم بالتركيز على التوصيفات ذات التقارن القوي» وتعمل على تصفية 
التوصيفات الأخرى ذات التقارن الضعيف. إضافة إلى نقطة التركيز (البؤرة)› 
بتم تقليل كمية المعلومات التي سيتم تصويرها في المخططات الرسومية. 

على سبيل المثال» يشرح الشكل 129 مقطعاً مكيراً لمستوى الوحدة 
الفرعية صنهصم/صهنوبز. انتقلت النقطة المركزية إلى الوحدة الفرعية صنعص كما 
ظهرت محتوباتها ورسمت في مستطيل. في هذا المثال» النقاط المحتواة هي 
الملفات المصدرية التي يشير إليها الشكل البيضوي. يبيّن الشكل البيضوي ألواناً 
مختلفة تشير إلى تطور الملف. زاد الملفان 2ءص إ۴ Main‏ و2اءمة۴وه؟ أكثر من 
غيرهما» كما هو مبيّن باللون الأكثر كثافة للشكل البيضوي المناظر. 


iD 
CaanToueart 


CGheractTooBarTabeanel) 1 
MainBüttönPafiê2 
١ ١ 


[ivislormaln] 


الشكل (9- 12): لقطة مكبرة لهيكلية الوحلة دوزي“ 


الحقوق عفر ظة 18۴۴ 2005 © 
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ترسم تقارنات التغيير في الوحدات والوحدات الفرعية مع الوحدة الفرعية 
داه" كمستطيلات إضافية فى المخطط البيانى. فى المثالء هذه الوحدات هى 
jvision‏ مع الملقات المصدري ية Vis2 9 VisDisplay2‏ والوحدة وووا‌kطc‏ مع ملفین 
مصدريين هما e1صPa HK FoderPanelو Send‏ . يتم استناء الملفات ذات تقارن 
التغيير الضعيف. 

الملفات ذات تقارنات التغبير الضعيفة تستثنى. بعد التشاور مع المطوّرين 
حول هذا العرض» وجدنا أن النوع الأساسي طب في 2«هاواا[. وهذه 
الحقيقة تبرر تقارن التغيير جزئياً لأن تهيئة الأجزاء الأخرى تتم عادة في أثناء 
البدء. لكن» أثمر الفحص التفصيلي للشيفرة البرمجية أن الرحدة 2ص0اوذال 
تفرض وصولية للعديد من آجزاء النظام من خلال متغيرات ثابتة. وهذا يجب 
آن يتم تحسینه. 

9 5 - 4 تقارن التغيير الانتقائي 

بما إن حدود الوحدة تكون مقيدة بشدة للتحقيق المتعمد فى بعض 
الأحيانء تدمج ۴۷٥1٤٥5‏ تصور مجموعات الملفات المختارة کل على حدة. 
بإمكان المستخدم اختيار مجموعة الملفات في أثناء التحقق من البرمجية 
باستخدام الفأرة ويترك ل ء«ماهبع آمر بيان تقارنات التغيير لهذه المجموعة من 
الملفات. على سبيل المثالء في المخطط الرسومي الموضح في الشكل 139 
اخترنا أربعة مlêlت‏ : Localizerg ImgView2وy VisDisplay2, MaioFrame2‏ . 
هذه الأنواع الأربعة هي تلك المسؤولة عن تقارنات التخيير القوية بين الوحدات 
الفرعية ”نوص ووذ و#عوص1 والوحدة الرئيسة «هاواہز. الملفات المختارة 
مجموعة في مستطيل» بينما تم طْيّ جميع الوحدات غير المختارة. هذا ويبيّن 
الشكل أيضاً تقارنات التغيير ضمن مجموعة الملفات وضمن الوحدات 
المطوية. 

يبيّن المخطط الرسومي في الشكل 13-9 أن جميع الملفات الأربعة 
المختارة مقترنة من حيث التغيير بملفات الوحدة صهنوابز. إضافة إلى ذلك ثمة 
تقارنات تغيير ضعيفة بين MainFrame2‏ والأنواع التابعة للوحدة ووواءطc.‏ 
وبمساعدة هذه الخاصية» يستطيع المستخدم اختيار مجموعات مختلفة من 
الوحدات والوحدات الفرعية والملفات وتجميعهاء ومن ثم تحليل تقارنات 
التغيير التي تربطها مع بقية التظام. 
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الشكل (9- 13): الشقارنات الانتقاثية بين llفlاتٽ VisDisplay2y Main Frae2‏ 
Localizerg IngView2y‏ . 
الحقرق فر ظة 18۴۴ 2005 © 


تقاس تقارنات التغيير ضمن إطار زمني: عدد الاعتمادات المشتركة التي 
تمت من خلال ملفين اثنين في أثناء فترة مراقبة معرفة. قد تكون فترة المراقبة 
محددة هنذ بداية المشروع أو آخر ستة أشهر من المشروع على سبيل المثال. 
فترة المراقبة قابلة للتعديل من قبل المستخدم عن طريق تحديد زمن البداية 
والنهاية. عند تغْيّر الفترة» تستجیب ء٥1٥۷٤‏ عن طريق إعادة حساب علاقات 
تقارن التغيير» ومن ثم إعادة رسم المخطط. 

يبيّن الشكل 14-9 الوحدات الفرعية لتقارن التغيير والملفات المصدرية 
للوحدة ص0 نوتہز خلال 18 شهراً من فترة التحقق آولاًء وأول 9 أشهرء اتا يبيّن 
المخطط الموجود في الطرف الأيسر تقارنات التغيير التي لم تحدث خلال 
التسعة أشهر الأولى بين ملفين مصدريين VisDisplay2, Main Frame2 laa‏ « 
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كما هو مبيّن في المخطط على الطرف الأيمن. نتيجة لذلك» تم تحديد التقارن 
بين الملفين لاحقاً خلال أنشطة التطوير. 


: ا 
SE‏ 
و ڪ 
i ۹ GD‏ 


{a} Change coupling of jvision within (0) Change coupling of jvision within firs 
emire history. nine nıonths. 
2DEvoLens الشكل (14-9): الشرجة الزمنية في‎ 
© 2005 18۴۴ الحقرق عفر ظة‎ 


يوفر لون الشكل البيضوي إشارات إضافية عن تطور الملفات المصدرية. 
على سبيل المثال» تقارن التغيير وألوان العرض و2سءااعص! أمر لافت. 

ثمة علاقة تقارن تغيير قوية بين الوحدتين» لكن عرض الملف نما بعد 
إضافة ما يزيد على 300 سطر من الشيفرة البرمجية» في حين بقي الملف 
۷2ع ثابتاً تقريياً عند 150 سطرآً من الشيفرة البرمجية» لكن يتم تعديلها 
باستمرار. من الواضح أن النوع المنفذ في الملف #ءااع"! بتطلب بينية أكثر 
ثباتاً ووضوحاً للحد من تأثير التغيير عند تعديل الملفات المرتبطة. 


9 6 أعمال ذات علاقة 

طوّر العديد من تقنيات وأدوات التصور في مجال الهندسة العكسية (أي 
إعادة التصميم) وفهم البرامج. من هذه الأدوات أاءطههه8 التي طورها فينيغان 
مەچ نصت۴ وآخرون» ون2 التي طورها کل من کازمان «هس2ه× و (13) کاریر 
کارپیر 6reنا۳ة)›‏ ووںمطد»8 التي طورها کوشکي ءعطعهه× وآخرون» واعن۸ 


. <httpi eww. iate.uniatuttgart.de/pa/ buha > (2) 
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التي طورها کل من مولر ءااتM‏ وکلاشینسکى رعەمنطەە1× وeاهم٥‏ التي 
طورها ستوري 0y‏ وآخرون. تستخدم هذه الأدوات تقنيات تصور شبيهة 
بالرسم البياني لإإنشاء عروض لإصدار شيفرة برمجية مصدرية معيّنة. تمثل النقاط 
(العقد) توصيفات الشيفرة البرمجية بينما تمثل الأطراف علاقات التبعية بين 
التوصيفات. هناك بعض الأدوات التجارية لإعادة التصميم وفهم البرامج. كما أن 
هناك بعض الأدوات التجارية لإعادة التصميم وفهم البرامج ك 40×أعة”1 
وطمaإعS0t0‏ واه . ترتكز تقتيات التصور الخاصة بناء ا هذه التقنيات› 
لكنها تتضمن أيضاً بيانات عن التطور وإصدارات الشيفرة البرمجية المصدرية. 
هناك امتداد آخر لهذه التقنيات يتمثل في استخدام عروض القياسات المتعددة. 


تستخدم تقنيات التصور خاصتنا العروض متعددة المقاييس التي عرفنا بها 
کل من 24٥ھ[‏ ودوکاس pucasse‏ 19“ وذلك لتصوّر الشيفرة البرمجية المصدرية 
مع مخططات رسومية غنية بقيم القياسات. قام الباحثان بدمج عدد من العروض 
المعرّفة مسبقاً في أداة #اسهء٣ءله٣"‏ مسهلة بذلك تصور البرمجية بتفصيل. 
تتبع العروض مبادىء مطابقة القياس من حيث إن قيم القياسات الأكبر تؤدي 
إلى وجود آشكال أكبر حجماً في المخطط الرسومي. 


استطاع 74ص1 والآخرون عرض وتقديم مصفوفة الط 04 باستخدام 
مفاهيم العروض متعددة المقاييس وأخذ إصدارات الأنواع المختلفة في الاعتبار. 
بنا على حجم القياسات التي تم تعقّبها من خلال عدد من الإصدارات» قام 
الباحثون بتعريف مفردات محددة لتصنيف الأنواع (مثلاً النابض» سوبرنوفاء 
القزم الأبيض. .. إلخ). بطريقة ممائلةء قام غيربا 0ء6 وآخرون بوصف 
منهجية قائمة على تلخيص قیم قياس الشيفرة المصدرية لعدة إصدارات تحدد 
الأنواع المعرضة للتغير . ثمة آداة تدعى العارض المصدري ثلاثي الأبعاد 
(۷32) تستخدم استعارة إ0طصهامص ثلاثية الأبعاد لعرض النظم البرمجية 
ويائات التحليل”" . العرض القديمي ثلاثي الأبعاد قائم على استعارة اع×ام ؟م8ممي 
ا#×اص"“ وتوسعها عن طريق تقديم التصورات في ثلائي الأبعاد. 


بالاضافة إلى تصور الشيفرة المصدرية تم تطویر علد من المتهجيات التي 
تركز على تصور الإصدارات وتاريخ التغيير للنظم البرمجية. على سبيل المثالء 


< http://www. thechiselgroup.org/creole > , (3) 
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قام ريغا ۸۷a‏ وآخرون بتحليل ثبات الهيكلية""" باستخدام الألوان لوصف 
التغيرات التي أجريت خلال فترة مجموعة من اللإصدارات. قام جينغوي وو ۷u‏ 
وآخرون بوصف طيف العطور*۴ الذي يصور التسلسل التاريخي لإصدارات 
البرمجية. أما ریسلبیرغ ٥۲ع۲‌طاeوور۸‏ ودیمییر 000۷۲ فقد استخدما تصو ر 
بسيطاً قائماً على المعلومات المتوفرة في نظم التحكم بالإصدارات لتوفير نظرة 
عامة عن تطور النظم” . أما فرانيا ه١١۷‏ وآخرون» فقد قدموا منهجية 
عهءءC۷5‏ التي تتيح للمستخدم التحقق تفاعليا من معلومات الإصدار والتخيير 
من مواقع التخزين في ٥۷58‏ من خلال عرض ذي توجه خطي. المنهجيات 
الأربع المقدمة في هذا الفصل تكمل التقنيات الموجودة وتوفر وسائل إضافية 
لتحليل تطور النظم البرمجية كمخططات هنبا أو الأشكال الكسيرية. 


إن عملية تحليل تطور النظم البرمجية هو نظرة إلى الخلف في تاريخ 
الإصدارات والتغيرات والعيوب والمشكلات. توفر مواقع تخزين البرمجيات ك 
8 وaاااzچBu‏ بیانات عن تاریخ الإإصدار والتغيرات والمشكلات إضافة إلى 
إصدارات الشيفرة البرمجية المختلفة اتی یمکن استعادتها وقياسها من مواقع 
التخزين. يتم ضرب مقدار البيانات اللازمة لتحليل تطور البرمجية بعدد 
الإإصدارات» وبالتالی يکون المقدار کبیرا. لمعالجة كمية البيانات هله تستخدم 
عروض عديدة وتقنيات تصور فاعلة. 


في هذا الفصل»ء عرضنا أربع تقنيات للتصور» ركزت كل منها على 
جوانب مختلفة من تطور البرمجيات. يركز عرض مقاييس التطور المتعددة على 
تصور الجوانب المتعلقة بتطبيق إصدار واحد من الشيفرة البرمجية المصدرية أو 
تطبيق عدة إصدارات. 


على سبيل المثال» يمكن استخدام هذه التقنية لتصور تطور الوحدات 
من حيث الحجم ودرجة التعقيد مسلطة الضوء على الوحدات التي أصبحت 
غير مستقرة. يتيح عرض تطور الميزات للمطورين تعيين مواضع تنفيذ 
الميزات في الشيفرة البرمجية المصدرية وتقييم تأثير التعديلات الوظيفية في 
النظام البرمجي. يمكن أن تستخدم للتواصل مع المستخدمين والمطؤرين. آما 
لتحليل سلوك التغيير في الوحدات البرمجيةء فيمكن استخدام عرض مساهمة 
المطورين. فهذه التقنية تصور الجهرد المبذولة لإصلاح مشکلات النظام 
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وعيوبه وتطوير النظام البرمجي. هناك أربعة آنماط تطور تميّز سلوك تغْيّر 
الوحدة التي تم تحديدها كالوحدات التي يعمل فيها عدد من المطورين 
بتوازن أو بطريقة غير متوازنة. أخيراًء تلقي تقنية عرض تقارن التغيير الضوء 
على الملفات المصدرية والوحدات التي تتغير مع بعضها البعض باستمرار. 
يمكن استخدام تصور هذه الاعتماديات المتقارنة المخفية في التحقق من 
جوانب القصور في التصميم (مثلأًء يجب أن تكون التغيرات محلية بالنسبة 
إلى الوحدة) ولتقييم تأثير التغيير. 

بالنسبة إلى هذه التقنيات الأربع» عرضنا أمثلة من دراسات الحالة الخاصة 
بمشروع موزيللا ذي المصدر المفتوح بالإضافة إلى نظام برمجي صناعي. فهي 
تبيّن بوضوح فوائد المنهجيات وتقوية فكرة أن تقنيات التصور المختلفة لازمة 
لتحليل مظاهر التطور المختلفة للتظم البرمجية. 


شکر وعرفان 
يوذ المؤلفون تقديم Jش>ر Marco D’Ambrosy Jacek Ratzinger ja JÛ‏ 
Michele Lanza‏ لمساهمتهم فى إنجاز هذا العمل. 


ثم اعتمدت بعض أجزاء العمل المقدم من قبل «مؤسسة العلوم الوطنية 
السويسرية 5۸۴ في إطار متحة المشروع «التحکم بتطور البرمجیات )٥05$٤‏ 
ومۇسسة 810۲ - سويسرا في إطار منجة المشروع «افضاءات التصفح متعدد 
الأبعاد لتطور البرمجيات ‏ sععهم۴۷08١.‏ 
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إدارة العمليات 


10 


الاختبار التجريبى گی هندسه البرمجيات 
جويسي (Giuseppe Visaggio) gl‏ 


0 - 1 مقدمة 

لمدة ما يقارب 30 عاماً في قطاع هندسة البرمجيات» كان الباحثون يطلبون 
من الممارسين استخدام نتائج أبحائهم لتحويلها إلى ممارسات مبتكرة أو 
استخدام الممارسات التي طوروها في مختبرات الأبحاث للحصول على 
منتجات برمجية وعمليات مبتكرة» في حين كان الممارسون يطالبوك بممارسات 
يمكن استخدامها للحصول على عمليات مبتكرة ومنتجات مدعمة بأدلة بهدف 
تقییم أهمية وجدوى العمليات والمنتجات والمخاطر التي يجب إدارتها في أثتاء 
مأسسة العمل. 

لسوء الحظ» يشير الباحثون عادة إلى المنافع التقنية لاستخدام عملية جدیدة 
أو أداة جديدة» متجاهلین فائدتها وقابلية تحولها عملياً. بثاءًَ على ذلك يتطلب 
الممارسون فهرساً بنتائج البحث» وهذا ما لا يتحول على واقع عملي غال)3:20 , 

أيضاًء الممارسات المتوفرة لا تكون دائماً مدعومة بالأدلة اللازمة لضمان 
فعاليتها في العمليات الفعلية أو قابلية تحولها ضمن أو نحو عمليات الأعمال. 


تساعد الأبحاث في مواجهة التوتر الناجم عن هذا الخلل والتغلب عليه 
عن طريق تطوير هندسة البرمجيات كعلم وإبعاده عن المظاهر التي جعلته يبدو 
أقرب إلى الفن منه إلى العلم” . في الواقع» يتطلب التطوير العلمي التحقق 
من النظريات والمبادئ والممارسات التى تكوّن المعرفة العلمية. إضافة إلى 
ذلك» قد تتتج الدراسات التجريبية دليلاً لشرح سبب أهمية قطبيق مبدأ جديد أو 
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تقنية جديدة (آي الابتكار). أخيراً» يمكن آن تسهم الدراسات التجريبية في بناء 
الاختصاصات التى يجب أن تتحول إلى ابتكار. ملخص ذلك أن الدراسات 
التجريبية قد تساعد في جعل هندسة البرمجيات جزءاً من المعرفة العلمية 
وتحويلها إلى ابتكارات ونشرها للآخرين. 

يعطي هذا الفصل ثركيباً للمعرفة التي جمعت في تصميم وتنفيذ 
الاستقصاءات التجريبية ۴1 المدمجة مع الخبرة التي تكونت في مشاريع البحث 
المنفذة تحت إشراف المؤلف في مختبر آبحاث هندسة البرمجيات في جامعة 
Bari‏ . 

هذا القصل مخصص لباحثي وطلاب هندسة البرمجيات الذين پرغبوك في 
فهم دور البحث التجريبي في تنفيذ أنشطتهم وفي نقل نتائج أبحائهم للمجتمع. 


دور البحث التجريبي في تحديد زمن ومکان تقديم تقنية جديدة آو ابتكار تقنية 


مع تقنية آخرى. يجب آن يكون لدى قارئ هذا القصل معرفة بعمليات وتقنيات 
وممارسات هندسة البرمجيات. 
الأقسام الآتية » تقدم الدراسات التجريبية مقدمة عامة عن : 
(آ) الدراسات التجريبية ودورها فى بناء التظريات والموافقة عليها. 
(ب) وصف أنواع الاستقصاءات التجريبية المختلفة التي يمكن تنفيذهاء 
(ج) إرشادات عن تصميم وتنفيذ استقصاءات تجريبية فاعلة من دون عيوب. 
بعد تحديد الجواتب الأساسية للاستقصاءات» يحلل هذا الفصل استخدام 
هله الاستقصاءات بهدف تحدید سمات هندذسة البرمجيات وإمهارها ببصمة 
علمية. أما مخاطر وتهديدات الاستقصاءات التجريبية فهي حرجة وحاسمة من 
حيث التنفيذ الصحيح وتفسير البيانات. في هذا المعنى» يتضمن الفصل قسماً 
مخصصاً لصحة المخاطر والتهديدات» وهذا القسم يلخص معظم المخاطر ذات 
الصلة ويتضمن إرشادات لتنفيذ تجارب للتخفيف من أثرها. إضافة إلى ذلك»› 


يقدم قسم الدراسات التجريبية في علم هندسة البرمجيات ما يأتي : 
(أ) مقدمة عامة عن مسارات التطوير في هندسة البرمجيات والحاجة إلى 
تکرارها. 
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(ب) تحليل المشكلات التي تظهر في آثناء تكرار الدراسات وتوفير 
إرشادات للتغلب عليها. 

(ج) تفاصيل عن أنواع معيّنة من التكرارات المستخدمة لاستخلاص 
المعرفة التي تعرف بعائلات التجارب. 

يصف قسم الاستقصاءات التجريبية لقبول الابتكارات ما يأتي : 


(أ) بعض التجارب المنفذة فى مختبر أبحاث هندسة البرمجيات حول 
ملاءمة الدراسات التجريبية فى المساهمة فى القبول. 


(ب) إضفاء الطابع المؤسسي على التكنولوجيا الجديدة. 

أخيراًء بناء الاختصاصات من خلال الاستقصاء التجريبي يدعم فكرة أن 
الاستقصاء التجريبي في هندسة البرمجيات يجب أن يساهم في توسيع 
الاختصاصات» كما هو الأمر بالنسبة إلى العلوم الأخرى. في هذا المعنى» يلخص 
القسم كيف توسعت الاختصاصات خلال عشر أعوام من عمر الأبحاث التجريبية 
في هذا النطاف. آما خاتمة القسم فتختم الفصل العاشر مع الاعتبارات التي تشير إلى 
القضايا التي لا تزال مفتوحة التي تتبع ما تم عرضه في الأقسام السابقة من القصل. 


10 _ 2 الدراسات التحرببية 
10 - 2 1 مقدمة عامة 


يبدأ التطوير العلمي ب () مشاهدة حدث معيّن ويهدف إلى صياغة قوانين 
ملزمة عالمياء و(ب) وضع نظريات تجريدية. الاستقصاء التجريبي بمعتاه الواسح 
هو رديف للدراسات الميدائية وهو عملية تهدف إلى اكتشاف شيء مجهول أو 
التحقق من صحة فرضية يمكن تحويلها عموماً إلى قوانين صحيحة شرعية. 
يشارك الباحث في استخراج وجممع البيانات التي تحدد مقدار المشاهدات 
اللازمة. يمكن أن تشمل المشاهدة تأكيداً ذاثياً؛ عموماًء تتم المشاهدات 
بالاعتماد على حواس الباحث كلها. ثمة أدوات كأجهزة الاستشعار تتيح لنا 
إجراء المشاهدات من دون استخدام الحواس. غالبا ما تكون هذه الأدوات 
إلكترونية وتمنح الباحث قدرات للمشاهدة. 

تجرى بعض المشاهدات صدفة؛ بينما يكون البعض الآخر دورياً. يكون 
الباحث مهتماً بالنوع الأخير من المشاهدات. يهدف بحثه إلى اكتشاف الأسباب 
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التى تحدد الآثار المُلاحظة على الأحداث. إضافة إلى ذلك إذا كانت الأحداث 
إيجابية» يجب أن تكون المسببات التى نتجت منها تلك الأحداث معروفة وذلك 
بهدف تكرارها. أما إذا كانت سلبية» فيجب أن تكون المسببات معروفة أيضاًء 
كن بهدف تجتّب مشل هذه الأحداث. 

في البداية» المسبّبات التي تحذد الأحداث الملاحظة تحدد الفرضية. 
والفرضية يمكن أن تكون مقبولة مبدئياً عندما تكون مدعومة بسبب منطقي يمكن 
اعتباره مقبولاً بالنظر إلى المعرفة الحالية في مجال الببحث نيابة عن المجتمع 
العلمي» يمكن أن يرفض الباحثون الفرضية. الفرضية تبقى «حدسا» إلى أن يقبلها 
العديد من الباحثين. حالما تشكل الفرضية/ الحدس» يقوم الباحثون المتحمسون 
لها بإجراء الاستقصاءات التجريبية لدعمها وإثباتها. على العكس من ذلك» يجري 
الباحثون الذين لا يشاركون في تلك الفرضية استقصاءات تجريبية لرفضها. 

في بعض الحالات» علاقة السبب - التأثير المؤكدة بفرضية أو حدس» 
على الرغم من آنها غير مدعومة بآي دليل» تحدث في حالات حقيقية كثيرة. 
هذه الخبرة يتناقلها الممارسون عندما تلبي الممارسات أهدافهم. في هذه 
الحالة» يسمى الحدث أو الفرضية «حدساً مها»*. 


تصبح الفرضية قانوناً عندما ندعم بدليل تجريبي راسخ. أما إذا لم يتم 
إثبات الفرضية بدليل كاف حتى تعبتر صالحة» يقال إنها تؤدي إلى مبدأً وليس 
قانون. يلخص القانون/ المبدأ المعرفة التى جمعها الباحثون فى أثناء الاستقصاء 
التجريبي وهو وسيلة لتحويل هذه المعرفة إلى عمليات أعمال. لذاء يتم تحليل 
البيانات التي جمعت في أثناء المشاهدات بهدف التحقق منها ودعمها أو دحض 
النظرية التي تمنع الفرضية 2# . 

پشرح القانون كيفية حدوث الحدث ضمن ظروف معيْنةء لكنه لا یشرح 
سبب الحدث. أما سبب حدوث بعض الأحداث ضمن ظروف محددة فتوضحه 
النظرية. أحياناًء تظهر النظرية قبل القانون؛ في هذه الحالةء يمكن للنظرية 
التوقع بالقانون والمشاهدات. لكن» يجب آن يثبت الباحث التظرية من خلال 
الاستقصاء التجريبي والمشاهدات. 


(«) الحدس المهني (عتاداسء8): مصطلح يشير إلى الطرق المستخدمة في حل المشاكل الإنسانية واللية 
باللجوء dM‏ التجارب أو الخبرات التقنبة. کما یعرف معجم اللغة العرببة بالقاهرة الحدس المهني بأته المقدرة 
النامية للفرد لحل المشاكل عن طريق البرة الطويلة (المترجم). 
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يمكن طرح مثال بالإشارة إلى قانون ١ه٣إه۴‏ حول إخفاء المعلومات* . 
لاحظ بارناس أن ما قام به المطوّرون في شركة فيليبس (9صناذط۴) طْبّق حدساً 
مهنياً تقليدياً على ت تصميم البرمجية: فقد كانت كل وحدة مصممة ذات أبعاد 

صغيرة» ويمکن فهمها مها ور متها بشكل مستقل عن المصمَم؛ وكانت واجهات 
الاستخدام بسيطة بما فيه الكفاية لشمولها في نطاق العمل وقد صممت بصورة 
مستقلة عن المصمم أيضاً. افترض بارناس أنه لتحسين إمكانية صيانة النظم 
البرمجية» يتوجب تنفيذ كل وحدة بشكل مستقل عن الوحدات الأخرى» وكانت 
الواجهات تعرض أقل مقدار من المعلومات الممكنة في ما يتعلق بتنفيذها. 
لانجاز نطاق العملء وكانت التقنية المقترحة ما يأتي: بإعطاء قائمة بقرارات 
المشروع› أخفي كل قرار في وحدة. كانت القرارات ذات احتمالية التغيير الأكبر 
نقذ في وحدات ذات علاقات قليلة مع الوحدات الأخرى في النظام. هله 
التقنية لم تعد تعتبر أن آداء النظام ذو أهمية أساسية. يجب التحقق من الأداء 
بعد إنتاج البرمجية وذلك باجرام اختبارات معيْنة» فإذا انتهك الأداء» يجب أن 
يتخذ المصمم قرارات جديدة تخفى في وحدات جديدة لتغيير إصدار النظام 
البرمجي السابق. هذه المعرفة نظرية في ما يعرف بقانون :Pn8‏ وملخصھا أن 
کل شيء مخفي یمکن تغییره من دون تحمل مخاطرة. 

لم نقذ بارناس أي دراسات تجريبية ليمنح هذا القانون الصفة الشرعية. 
استخدم العديد من الباحثين هذا القانون لكن لم يقم أي منهم بتكراره أو نتشر 
نتائجه المهمة لإثبات صحته وإمكان تعميمه عالمياً. اذأ من الأصح أن يسمى 
مدا بدلا من «قانون». 


يمكن تمرير النظرية الكامنة في هذا القائون كما يأتي. بإعطاء المحاذير 
الآتية» إخفب قرارات المشروع البرمجي في وحدة ووحدات تصميم بحيث () 
تكون محتوياتها مستقلة عن بعضها البعض»؛ و(ب) واجهاتها لا تعتمد على تخير 
محتويات الوحدة. التأثير الناتج هو كما يلي: يرتبط كل تعديل في المتطلبات 
بتغيير في أحد القرارات أو أكثرء وبالتالي تغيير في إحدى الوحدات أو أكثر؛ 
المتابعة بين القرارات والوحدات تتيح لنا تحديد التأثير الأولي في التعديلات؛ 
يضمن بات الواجهة آن التعديلات التي تجرى على كل وحدة متغيرة لا تؤثر 
فى غيرها من الوحدات المرتبطة بها؛ إن استقلالية المحتويات بين الوحدات 
يتطلب أن يكون المطرر هو الوحيد الذي يعرف محتويات الوحدة المتغيرة. 
شكرآً لهذه الكمية المحدودة من المعرفة المتطلبةء الصيانة هي الأكثر سرعة 
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(يمکن تنفيذ التعديلات بالتوازي هن قبل عدد من المطورّرين موافق لأعدد 
الوحدات التي يجب تعديلها من دون أن تتداخل أعمالهم مع بعضهم البعض)ء 
التكلفة ذات تأثير (التأئير الأولي للتعديلات يتناسب مع نطاق العمل أو مع 
التغيير المطلوب» بينما يكون التأثير الثانوي محدودا)» والموثوقية (تحدَّد 
الوحدات التي بتم تعديلها من خلال طلبات تغيير محددة). 

من وجهة نظر الاستقصاء التجريبي ([5): إن المظهر المركزي الذي يمكن 
اعتباره اقتراحاً بُعبّر عن علاقة «سبب - تأثير» بين بنيتين نظريتين» يؤسس إلى 
بنية سيبية تعيّر عن أسباب ناجمة» وبنية تأثير تصف التأثيرات المشتقة. وتربط 
النظرية بين الفرضيات بواسطة بُنى محكمة““» كما هو مين في الشكل 1-10. 


الشكل (10- 1) : مفاهيم أساسية للاستقصاء التجريبي وعلاقاتها مع بعضها البعض 


يهدف الاستقصاء التجرببي إلى ملاحظة تأثير التغيير على أحد العوامل أو 
أكثر. المشاهدات التي يتم تنفيذها مع الاستقصاء هي نتيجة المعالجات؛ كل 
عملية معالجة تُميّز بقيمة محددة لكل عامل من العوامل. يتم التعبير عن هذه 
العوامل من خلال متغيرات مستقلة. القيم التي يمكن أن تفترضها المتغيرات 
المستقلة تسمى «مستويات». ينتج من تنفيذ أنشطة الاستقصاء تأثير أو أكثر يعبر 
عنها بالمتغيرات التابعة التي تكون نتائج الاستقصاء. يجب أن يتم تنفيذ 
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الاستقصاء التجريبي في سياق موصوف بمجموعة من الخصائص التي يجب أن 
لا تتغير في أثناء الاستقصاء؛ وتسمى هذه الخصائص بالعوامل. عندما يكون 
لأحد العوامل أو أكثر تأثير في استجابتهاء وهذا أمر لا يهمناء فإن قيمها 
تحجب؛ تسمى مثل هذه المتغيرات بالعوامل المانعة. نأخذ بالحسبان الأشخاص 
الذين يعملون في مجموعة أو كتلة ونعتبرهم بقيمة العوامل المانعة نفسهاء 
بحيث نتمكن من دراسة تأثير معالجة كتلة فقط. إذا كان لدينا العديد من الكتل 
ذات قيم مختلقة عن العامل المائع نقسهء فإنه لا يمكن دراسة التأثير بين الكتل. 
يتم تنفيذ المهام في أثناء الاستقصاء من قبل المطؤرين كعيّنات تجريبية. إن 
تحقيق هدف الاستقصاء يشكل وحدة تجريبية. 


على سبيل المثال» افترض أننا نتحقق مما إذا كان اسلوب التصميم الجديد 
ينتج برمجية بجودة أعلى من أسلرب التي المسعخدم يت . يتم تنفيذ تجربة 
بأسلوب التصميم الذي له عامل بمستويين: آسلوب التصميم الجديد والأسلوب 
القديم. كل مستوى يُعتبر معالجة. آما المسؤولون التجريبيوت فهم المصممون 
ذوو الخبرة المحددة مسبقاً. أما العوامل المتغيرة فقد تكون المتغيرات التي تعبْر 
عن الخبرة كالمصمم الذي يعمل مع المسؤولين التجريبيين. الوحدة التجريبية 
يكون عدد الأخطاء (العيوب) الموجودة في التطوير. إذا استخدم بعض 
المصممين إحدى طرق التصميم (أي التصميم كائني التوجه)ء فإن بإمكانهم 
جمعها في مجموعتين› واحدة بوجود خبرة ة كالخبرة ة في التعامل مع العامل 
المانع أو خبرة في هذا الأسلوب المستخدم» وآخرى من دون ی بهدف 
التقليل من تأثير مثل هذه الخبرة. 


0 - 2 - 2 استراتيجيات الأستقصاءات التحريبية 


فى البحث التجريبى» يكون الباحث مسيطرا على بعض ظروف التنفيذ 
وعلى المتغيرات المستقلة التي يجب دراستها. حسب الحالة العي ينفّذ 
فيها الاستقصاءء يمكن أن يتم استدعاؤها في بيثة حيوية 0نس هز" إذا 
كان الاستقصاء ينْفذ على عمليات الإنتاج ضمن مشروع قيد العمل أو في 


(«) في بيئة حيوية (باللاتينية «٠نه‏ صة)» يطلق هذا المصطلح على العمليات أو التعديلات التي تحدث في 
نفس بيئة التشغيل (المترجم). 
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بيقة المختبر ١٣ان‏ صز" إذا كان ينقَذ فى بيغة مختبر معزولة. 


بناء على مستوى التحكم بالمتغيرات» يمكن تصنيف الاستقصاءات كما 
يآتي: المسح (الدراسة)ء تحليل ما بعد الحدث (يعرف أيضاً بتحليل بأثر 
رجعي)» استقصاء المشروع؛ أو التجربة المسيطر عليها (أو تعرف بالتجربة). 


المسح هو دراسة تجريبية يتم فيها جمع البيانات من الأطراف موضع 
الببحث من خلال الاستبياتات أو المقابلات. وقد تكون بأثر رجعي حيث تجرى 
على الخبرات المجمعة من الأشخاص الذين استخدموا الأدوات أو الأساليب أو 
العمليات المستهدفة في الاستقصاءء أو قد تكون دراسة تمهيدية» آي إنها تجمع 
الآراء عن الابتكارات التي يجري الاستقصاء عنها مسبقاً. 


مثال على ذلك» من المنطقي بيان مسح حول رضا الطلاب عن مقرر هندسة 
البرمجيات أجرته إدارة المعلوماتية في جامعة 8i‏ . أجري هذا المسح عن طريق 
توزيع استبيان على طلاب المادة بعد آن تقدموا للامتحان. جاب الطلاب حسب 
خبراتهم ومعرفتهم التي حصاوها في آثناء الفصل الدراسي. أظهر تحليل بيانات 
الإجابات ما إذا كانت التغيرات التي أجريت فى أثناء الفصل الدراسى قد اعترف 
بها الطلاب إيجابياً أم إذا كان لهم عليها بعض الملاحظات والتعليقات. في ما 
يلى» أخذت البيانات الرقمية فى التقارير فقط؛ كما تضمن الاستبيان ملاحظات 
نصية حفزت الطلاب على الإجابة. لم تؤخذ الملاحظات في التقرير لأسباب تعلق 
في المساحة. لفهم الاستبيان أفضل ما يكون» من الأهمية بمكان الإشارة إلى أن 
الطلاب قاموا بتنفيذ مشروع قاموا باختياره من بين مجموعة من المقترحات. بعض 
أعمال المشروع اقترحها الشركاء في القطاع الصناعي وكانت تتضمن مقترحات لا 
تشير مباشرة إلى محتويات المادة الدراسية» بل إلى الكفاءة المكتسبة فى أثناء 
القصل الدراسي من المادة. تعرف تلك الأعمال بأعمال المشروع الصناعية. ‏ 

آما بعض مقترحات المشروع الأخرى فقد قدمها مدرسو المادة» وكان 
محتوى المقترحات يشير إلى محتويات المادة مباشرة. وتعرف تلك الأعمال 


بأعمال المشروع التعليمية. يبيّن الجدول 1-10 الاستبيان» في ما يوضح الشكل 
2-10 النتائج المحصلة بعد توزیع الاستبيان. 


(«) في بيئة المختبر (باللاتينية هان« هة» ومعناه حرفياً في الزجاج)» يطلق هذ المصطلح على إجراء 
العملية في المختبر خارج البيئة الأصلية حيث هئاك سيطرة أكبر نوعاً ما (المترجم). 
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تضمنت آراء الطلاب مقترحات بأن يقوم المدرسوك بتحسين محتثوى 
ومضموك المادة وكيفية توفیرها. من الجدول 2-10 يمتنا آن نری أن مستوی 
الرضا بقى ثابتاً بعد التحسينات التى اقترحها الطلاب. 


يتكون استقصاء تحليل ما بعد الحدث (بتحليل بأثر رجعي) من تحليل 
البيانات المجمعة في البيثة الحيوية ۷0اه طن لكن لأهداف تختلف عن تلك 
الاستقصاءات التي تتم في المشاريع المنقذة أصلا. فهذا النوع من الاستقصاءات 
يستخدم لتأكيد أو نفي إحدى الفرضيات (أو أكثر) عن طريق التحقق من أن 
البيانات التي جمعت من المشاريع المنْمَّذة قادرة على محاكاة متغيرات 
الاستقصاء. لهذه الطريقة مخاطر منخقضة وذات تكلفة منخفضة وتضمن 
صلاحية تجريبية منخفضة أيضاً. عادة ما تكون الأدوات الإحصائية عبارة عن 
تحليل سلاسل البيانات التاريخية والتنقيب عن البيانات. 


مثال على ذلك الاستقصاء بأثر رجعي عن إطار عمل متعدد العروض لتصميم 
خطة قياس هدفية التوجه. هناء نوفر المحتويات الضرورية للاستقصاء؛ بإمكان 
القرّاء المهتمين الرجوع إلى المرجع*. على الرغم من وجود دليل على التطبيق 
الناجح لبرامج القياس هدفية التوجه في القطاعات الصناعيةء إلا آنه لا يزال هناك 
العديد من القضايا المفتوحة: أبعاد خطة القياس وتعقّد التفسيرات والاعتماديات 
بين الأهداف والمواعيد الزمنية لأنشطة القياس. تتضمن نظريتنا بناء هيكلية برنامج 
القياس بحيث تكون الأهداف متماسكة داخلياً من حيث عدد ونطاق المقاييس 
بينما تكون علاقاتها مع بعض البعض ضعيفة وذلك لإدارة تعقد التفسيرات. حتى 
تکوك هذه النظرية فعالةء نقترح منهجية إطار العمل متعدد العروض ۷٣‏ الٿي 
توفر دعمأ لتصميم خطة قياس صناعية ذات هيكلية كبيرة. أساسياً» صنّفت 
أهداف تحاليل منهجية إطار العمل متعدد العروض كما يأتي: أهداف العملية 
(sلھه‏ 85٥إ۴)‏ _ تنحو إلى تقييم عامل الجودة للفائدة قياساً بالطريقة أو 
الفعالية؛ أهداف إدارة المشروع )lsےgo PM )Project Management‏ - تنحو إلى 
تقييم النشاطات اللازمة للتخطيط لتنفيذ المشروع والتحكم به؛ كفاءة أهداف 
الاستٹمار (ەلھەG [nvesimen‏ ۴ وع۴) ۴1 _ تقييم المظاهر كنسبة التكلفة - 
المنفعة والمخاطر المحتملة. يعرف كل مظهر من هذه المظاهر كعرض. 

يتم الاستقصاء عن هيكلية خطة القياس عن طريق تتبع الأهداف باستخدام 
جدول الإسناد الترافقي لعرض الأهداف. يمكن تعريف ذلك بوضع الأهداف في 
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أسطر الجدول ووضع العروض كأعمدة (انظر الجدول 3-10). إذأًء فإن كل 
مدخل (×) في الخلية (ة) في الجدول يعني أن الهدف ذا الترتيب طاة له 
مقاییس ترتبط بالعرض ذي الترتيب طاز. 


5 


الجسول (1-10) 


ما هو رأيك في محتوى الماد ل متوازن جيدا 
ما هي المواضيع التي يجب دعمها بمزيد من التفاصيل؟ 0 غير متوازن 
ما هي دراسات الحالة التي نفذتها؟ [] دراسة حالة عن القطاع الصناعي 


دراسة حالة تعليمية 
برأيك ما هو أكثر الخيارات فعائية للماد؟ (يمكن انتقاء أكثر دراسة حالة تعليمية 
عن خیار)۔ دراسة حالة عن القطاع الصناعي 


تمارين مخبرية 


um e mil 


تمارين صفية 

١‏ أسئلة مكتوبة 

0 غير ذلك 

ددا ا[ کک ووا ی ج جو ی اس ی چ چ مت ج وی م چ حب پس ی بو 


ما هو رأيك في دراسة الحالة عن القطاع الصناعي؟ (يمكن ]1 تحسن من مستوى الاحترافية 


انتقاء أكثر من خيار). تتطلب مجهودا کبیرا 
تجربة سلبية 
عزز إجابتك کک چ کے ی ی 
بشكل عام» هل تعتبر أن المادة: [يمكن انتقاء أكثر من خيار). [] شاقة 
[| مفيدة 
عزز إجابتك و کج ی ی ی 


صف فة جوب ضعفةاللمادة: 
1 س ا ت س 


e .2 


ھ4 
EEE E E EEE EEE O TE E EOE EEE ETE Ê‏ 
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3 


عدد الاستبيانات الموزعة 


الحدول (10 


2 


4 
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المادة: (يمكن انتقاء 
آکثر من خپار). 


CESED ERE CES 
EE ESEESEA 


0.008 


#ependen cies‏ وها العدد يزيد كلما زاد عدد العروض التي تؤخ بعين 
الاعتبار. ويتم حساب هذا المؤشر بالمعادلة الآتية : 


k 
#Dependencies = 3 (N, — |) 
=| 
حيث ٤ء إجمالي عدد الأسطر في جدول الإسناد الترافقي» وال عدد‎ 
." مرات × في جدول الإسناد الترافقي» مع الإشارة إلى السطر ذو الترتيب‎ 


الممدول (10- 3) 
الإستاد الترافقي لعرض الأهمداف 


س 
سا ]ا ت کا ]س سی سس 


المؤشر الثاني هو كثافة التبعيات» ويقيّم مقدار قوة التبعيات؟ تم حسابها 
حسب المعادلة الاآتية : 
غدد التبعيات 
كثافة التبعيات = 


[# الأسطر × # الأعمدة) - # الأمداف 

خطة القياس المصممة جيداً بجب أن تحدٌ من كلا المؤشرين. 
للتحقق من صحة إطار العمل متعدد العروض» يجب استخدام خطة قياس 
هثوافرة؛ تم تحديد الخطة ضعن هشروع منفَذ» ومن ثم طبقت المنهجية المقتر حة 
عليها. كان الشحقق قائثماً على تحليل كيف كانت هيكلية -خطة القياس ستكون لو 


استخدمت منهجية إطار العمل متعدد العروض لتصميمها. أولاًء تم تنفيذ التحقق 
المتقاطع. ثم عقدت مقارنة بين جداول الإسناد الترافقي لعرض الأهداف لخطة 
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القياس القديمة غير المهيكلة (خطة )۸N58‏ والخطة الجديدة المهيكلة (خطة 8)» 
وعرضت المقارنة مع إطار العمل متعدد العروض في الجدولين 4-10 و5-10 
على التوالي. كما يبيّن الجدول 6-10 على الرغم من أن عدد الأهداف الإجمالي 
أكبر في الخطة 8 إلا أن معدل تعقد التفسير أقل. وهذا يعود إلى عدد المقاييس 
القليل لكل هدف متحقق كنتيجة لتطبيق إطار العمل متعدد العروض على الخطة 
8, عدد التبعيات وكثافة التبعيات يساوي صفراً. لذاء يكون الاستقصاء بأثر 
رجعي هو أول عملية تحقق إيجابية من صحة إطار العمل متعدد العروض. 


الحدول (10--4) 
اس تر د نراقي للخطط NS (NS - Plan)‏ 


تصميم سيناریو عر س ا كفاءة 
ار س س 


الجدول (5-10) 
لاساد دار اتراي للخطة $ 
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ES E E E ETT 
SE TT 


ه كفاءة الاستشمار» 1 


E. E E I E E LEST 


يتم تنفيذ الاستقصاء عن المشروع في بيثة المشروع نفسه للتأكد من 
عمليات تطوير آو إنتاج أو تقييم التطبيقات الجديدة أو العمليات آو التقنيات أو 
الأدوات. وهذا مكلف ويحتمل مخاطر كبيرة نظراً إلى أنها تتطلب مطرّرين 
محترفين عليهم العمل حسبما يقتضي تصميم الاستقصاء؛ فهو يتطلب أن يتم 
تنفيذ تصميم الاستقصاء مع مراعاة الشروط وجمع المقاييس التي يتطلبها 
التصميم. وبالتالي» فإن الوقت المطلوب لتنفيذ المشروع يكوت أكبر مما هو 
متوقع غالباً. أيضاًء قد يحدث أداء أسواً من الأداء المتوقع من دون إجراء 
معالجة. خلاصة ذلك إن هذا النوع من الدراسات مكلف ومحفوف بالمخاطر 
بالنسبة إلى جودة المنتج وأوقات تنقيذ المشروع التجريبي. بناءَ على ظروف 
التنفيذء يمكن تصنيف استقصاء المشروع كما يظهر في الجدول 7-10. 


الحدول (10- 6) 
الخغير التابع 
| الياناتالجمسة | اح | ا 
a E E‏ 


عدد القپاسات 
عدد اشاس لكل عدف (معدل) 3.5 20.18 


سيت لإ ل ف 
0.27 


كثافة البمیات 
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الحدول (7-10) 
تصنيف استقصاءات المشروع 


EE a 
مد یی او ست‎ 


للتحقق من فعالية المعالجة» يمكن مقارنة مشروعين: أحدهما يطبق 
المعالجة والآخر مشروع تحكم يمذ في ظروف عادية من دون تطبيق أي معالجة. 
نادراً ما تكون الشركة على استعداد لتنفيذ مشروعين بنطاق العمل نفسهء بمراعاة 
أن أحدهما يتمذ لأغراض تجريبية فحسب من دون اعتبار الأغراض الإنتاجية. 
إضافة إلى ذلك» من الصعوية بمكان إنتاج السياق نفسه لمشروعين» أحدهما يتمذ 
مع معالجة والآخر ينفذ ضمن شروط طبيعية. بهذه الطريقة. لا تقارن البيانات التي 
جمعت في المشروع الأول بالبيانات التي جمعت في المشروع الثاني. غالباً ما 
تستخدم السلاسل التاريخية ك 01» 02...» 1× 01ء 02ء...» 02؛ 
2 .. . حيث 01 المشاهدات للبيانات المجمعة وت× المعالجات. أما الزمن 
بين مشاهدتين متتابعتين فتكون ثابتة ويشار لها بزمن العيّنة“. آما الأداة 
الإحصائية المستخدمة في هته الحالة فتتضمن أيضاً تحليل للسلاسل التاريخية 
يجب التحقق من أن اتجاه المشاهدات قبل المعالجة يختلف عته بعد المعالجة» 
وأن الفرق بين الاتجاهات يعزى إلى المعالجة. 

مثال على ذلك سنأخذ فى الاعتبار خبرة الشركة التى كانت تواجه مشكلة 
في تقليل طلبات صيانة تطبيقات الأعمال والحد من فترات الانتظار بهدف 
تحسين مستوى الرضا. تفاصيل هذا المثال موجودة في المرجع“ 

النظرية المفترضة هي أن تعميم قدرات التطبيق قد تلبّي احتياجات طيف 
واسع من المستخدمين. بذاء عتد م اة عملاء جدد أو آن استخدام التطبيق 
يتغير مع الزمن بالنسبة إلى العملاء الموجودينء تكون معظم طلباتهم متنبً بها 
من التطبيق نفسه»ء تبعا لذلك» يقل عدد طلبات الصيانة. إذا كان بالإمكان 
تكييف التطبيق مع متطابات العميل من دون تعديل البرمجية» فإنه يمكن إنجاز 
ذلك في فترة قصيرة. إذا كان للتطبيق هيكلية قائمة على الوحدات» ومستوى 
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التعقيد المنخفض لم يتأثر سلبياً بطلبات الصيانة السابقة» فإنه يتوقع عدد مرات 
الصيانة لن تزيد مسألة الوقت سوءاً. 


لتحقيق هذه النظرية» قامت الشركة لنموذج تحليل جديد للتطبيق بالرجوع 
إلى ملف مستخدم نظري يعمم طلبات المستخدم الفعلية؛ يطلب كل عميل 
مجموعة من الإمكانيات. إضافة إلى ذلك» يتم تطوير أسلوب جديد للتصميم 
مشترك مع الوحدات والأنماط المعلمية قادر على ضمان إعادة استخدام 
البرمجية» ودرجة تعقيد الهيكلية المنخفض وتخصصية سلوك التطبيق عن طريق 
تخصيص قيم لمجموعة من المعاملات. أخيراً» تم تحديد عملية صيانة تعرف 
بالتحسين التكراري قادرة على الحفاظ على وحدات البرمجية وإمكانية تتبعها. 
للتحقق من صحة هذه التقنيات» تم تطبيقها على بعض التطبيقات المستخدمة 
في القطاع العمصرفي» لكنها لا تستخدم في الإدارة العامة الحالية آو في القطاع 
الصحي. في القطاعين الاأخيرين» تبقى التقنيات نفسها من دون تغيير. تم جمع 
البيانات على أساس الفصل؛ بدأ تأثير المعالجة في القطاع المصرفي خلال 
عام؛ في العام الثاني» ظهر تأئير التطبيقات المتوارئثة في القطاع نفسه» التي تَمْ 
تجديدها حسب الأنماط الجديدة والهيكلية القاقمة على الوحدات المسشخدمة 
في التطبيقات الجديدة. ببيّن الشكلان 2-10 و3-10 طلبات الصيانة في القطاع 
الذي يتم تطبيق المعالجة عليه» وفي القطاعين الأخريين اللذين لم يعالجا. يبيّن 
الشكلان 4-10 و5-10 معدل زمن الانتظار لتنفيذ الطلبات المصنفة من قبل 
التطبيقات في كل القطاعات. 
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1 12 13 4 M1 I2 W3 N4 UMA U2 U3 I4 
الفترات الستوة‎ 


الشكل (10- 2): اتجاهات صيانة الاعتراضات التي تنطلبها البنوك 
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يبيّن الشكل 10 _ 2 أن المعالجات ذات تأثير وثيق الصلة بتحسين وتعزيز 
البرمجية. في الواقع» ينخفض الاتجاه على نحو ذي مغزى بعد المعالجة. 

تم تأكيد هذه النتيجة في الشكل 10 - 3: في القطاعين اللذين لم يتعرضا 
للمعالجة» إتجاه عدد التعديلات كبير ويزيد مع الوقت. لا بوجد هناك تغييرات 
مهمة للصيانة التصحيحة؛ لذاء لا تؤثر هذه المعالجة إيجابياً في انتشار الخطا 
في البرامجح. 


1 12 13 4 N1 M2 N3 U4 MA N2 U3 UA 


الفترآت النشنوينة 


الشكل (10- 3): اتجاهات صيانة الاعتراضات التي تنطلبها الإدارة العامة المحلية 
والمنظمات في القطاع الصحي 


يشير الشكل 10 - 4 إلى أن فترة الانتظار لتلبية طلب تقل بعد المعالجة؛ 
مرة أخرى» هذا الأمر مثبت عن طريق مراقبة أن الفترة تقل عند توسيع عملية 
وضع بنية تركيبية للبرامج لتشمل النظم المتوارئة. 

من الأهمية بمكان ملاحظة أن الاتجاه في الشكل 10 - 4 يميل نحو خط 
المعاربة» في حين يميل في الشكل 10 - 5 إلى زيادة مطردة. وهذا يشير إلى 
أن معالجة الاستقصاءات التجريبية تفلل من تدهور حالة البرمجية. أخيراً 
لاحظ آنه لإجراء التصحيح اللازم» يقل الاتجاه للتطبيقات التي أنتجت باتباع 
العمليات التي تكون عرضة للمعالجة. وهذا يعني أن المنتج البرمجي الناتج 
أكثر قابلية للصيائة. 
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التحسين/التعزيز ي 
التمحيح س 


أيام التقويم 
š‏ 3 


1 |12 3 4 M1 M2 U3 ONA M1 H2 U3 U4 


الفقرات السنوية 


الشكل (10- 4): اتجاهات زمن الانتظار لصيانة الاعتراضات التي تتطلبها البنوك 


يتم تنفيق التجربة «تجربة/ تحكمة في بيئتها (أي بوجود عوامل متحكم بها) 
لإحراز معرفة جديدة. على وجه الخصوص» برغب الباحث في إثيات آن 
المعالجة التي خطط لها في التجربة لها علاقة سببية بالمتغيرات التابعة. تقسم 
الفرضية المفاهيمية للتحقق من صحة ذلك إلى فرضيتين فعالتين : 

فرضية العدم» م۴: تحدد ما برغب الباحث في تحقيقه» وهو آنه ليس 

صحيحاً لعيّنة الدراسة. الهدف هنا هو رفض الفرضية مع أكبر دلالة ممكنة. 

الفرضية البديلة» ,11/۴: تحدد التوكيد لصالح فرضية العدم المرفوضة. 

تتميز التجربة بالتصميم الذي يطبق المعالجات على مواضيع الدراسة بهدف 
مراقبة التأثير. على سبيل المثال» إذا كان العامل 1 (لغة برمجة) بمعالجتين (لغة 
جافا ولغة سي) وعلاد أفراد المجتعع التجريبي س؛ فان کل موضوع کون 
عرضة لكل معالجة بتنفيذين تجريبيين حسب الجدول 8-10 . 

إن تخصيص كل موضوع من مواضيع الدراسة يخضع لتوليفة من معالجتين 
عشوائيتين » بحيث يتوزع مجتمع الاستقصاء التجريبي بالتساوي بين المعالجتين. 

عندما بؤدي عدد العوامل وعدد المستويات لكل عامل إلى عدد كبير من 
التوليفات» يتم تصميم المشروع التجريبي بتقنية التصميم العاملي المخفض. 

بين الجدول 9-10 مثالا بوجود ثلاثة عوامل (طريقة الصيانة» واللغة ونوع 
الصيانة)» لكل منها مستويان محتملان هما على النحو: إصلاح سریع ۴© أو 
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تحسین تکرارې »1٤‏ لغة جافا أو لغة + +€» صيانة تصحيحية ٣ه‏ أو صيانة 


تطويرية Ev‏ , 
105 
100 
وی و و 
E,‏ 
A‏ 
س 
التحسين/التعزيز ي ی ا 4 
ا ت i E‏ 
4 80 
75 
N1 U2 U3 4 U1 N2 N3 N4‏ 14 13 2 1 
الفكرات الستوية 


الشكل (5-10) : اتجاهات زمن الانتظار لصيانة الاعتراضات التي تشطابها اللإدارة 
العامة المحلية والماظمات في القطاع الصحي 


الجدول (10- 8) 
مثال عل الموضوعات التجريبية 
سے في استقصاء ته س ا 


هناك عدد من الاختبارات الإحصائية المختلفة الموصوفة في الأدبيات التي 
يمكن استخدامها لتقييم نتائج التجربة. بتضمن اختبار الفرضية مخاطر مختلفة 
يشار إليها بالخطا من النوع الأول والخطا من النوع الثاني. بحدث الخطاً من 
النوع الأول عندما يشير الاحتبار الإحصائي إلى وجود علاقة نمطية حتى لو كان 
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لم يكن هتاك نمط فعلي: رفض فرضية الحدم ۴10 عندما تكون فرضية اعدم ۴0 
صحيحة. يحدث الخطاً من النوع الثاني عندما لا يشير الاختبار الإحصائي إلى 
علاقة نمطية حتى لو كان هناك نمط فعلي: عدم رفض فرضية العدم ۴10 عندما 
تكون فرضية العدم م۴ خاطئة. للإكمال» تكون قوة الاختبار الإحصائي هي 
احتمالية أن يرفض الاختبار م8 عتدما تكون خاطئة. كما إنها متممة 1 لاحتمالية 
الخطا من النوع الثاني. 

تقسم جميع الاختبارات الإحصائية الفضاء العيني (فضاء المعاينة أو 
الحدث) إلى جزءين متممين: مساحة لقبول فرضية العدم ۴ ومساحة لأرفض 
فرضية العدم «۴. في تجربةء إذا كانت القيمة الإحصائية لاختبار تقع في 
المساحة الأولى» يتم قبول فرضية العدم؛ ما إذا وقعت في المساحة الثانية» فيتم 
رفض فرضية العدم لصالح قبول الفرضيات البديلة. تقسم جميع الاختبارات 
الإحصائية المساحة بحيث تكون المساحة الأولى أكبر من المساحة الثانية» وذلك 
لتجنب الاستنتاجات الخاطثة - آي قبول الفرضية البديلة :۴ عندما لا تكون 
صحيحة بالفعل **. بمعنى آخر» عند تنفيذ اختبار ماء يكون من الممكن 
في العديد من الحالات حساب أقل أهمية ممكنة لرفض فرضية العدم: القيمة م 
عندما تكون القيمة ص أكبر من 0.05ء يتم رفض ه۴؛ كلما كانت قيمة م أقل› 
زادت أهمية الرفض. 


الجدول (10- 9) 


مثال على الموضوعات التجريبية - التوزيع في استقصاء ثلائة عوامل 
(کل عامل بمعاتین) 


Q.F. C+ +, EY I.E., Java, Cor 
I.E.; C+ + ,Ev Q.F.,J, Cor 


I.E., Java, EV Q.F.,C+ +, Cor قش‎ 


LE;C+HLEV | QF. Java, Cor | S| 


يوفّر الإحصاء أنواعاً عديدة من الاختبارات التى يمكن تصنيفها إلى معلمية 
(nonparametric) ãgnlaa yıêg (parametric)‏ , 
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ترتكز الاختبارات المعلمية على النموذج الذي يتضمن توزيعاً محدداً. أما 
الاختبارات غير المعلمية فلا تآخذ نفس نوع الافتراضات في ما يتعلق بتوزيع 
العوامل. يلقي الجدول 10 - 10 نظرة عامة عن الاختبارات المعلمية أو غير المعلمية 
لتصاميم مختلفة للتجربة ؛ لمزيد من التفاصيل»؛ راجع المراجه 59 و , 

كمثال» نقدم لمحة عامة عن تجربة مسيطر عليها من حيث شمولية وفعالية 
تصميم خطة القياس المصممة باستخدام إطار العمل متعدد العروض ١×۴‏ 
الموضح مسبقاً في هذا الفصل. لمزيد من المعلومات» يمكن للقراء المهتمين 
الرجوع إلى المرجع”. سياق التجربة هو المادة التعليمية «هندسة البرمجيات) في 
جامعة باري. تمت صياغة هدفين من أهداف البحث لتقييم كفاءة وشمولية 
الخطة 8 مقارنة بالخطة :N×S‏ 


"0: لا يوجد فرق في الكفاءة (الجهد المبذول في التفسير) بين 
تفسيرات الخطة 8 والخطة 8× 


": هناك فرق فى الفعالية بين الخطة 8 والخطة ۸×8. 


2: هناك فرق فى الشمولية (التفسيرات معرضة للخطا) بين الخطة 8 
والخطة 8×, 


۳ : لا يوجد فرق فى الشمولية بين الخطة 8 والخطة ,١8‏ 


المتغيرات التابعة هي : الجهد المبذول» أي الفرق بين زمن بدء وزمن 
انتهاء تفسير خطة القياس كاملة (الخطة 8 أو الخطة ۸8)؛ التعرض للخطاء أي 
عدد الاستنتاجات غير الصحيحة فى تفسير أهداف خطة القياس (الخطة 8 أو 
الخطة ۸8). آما مجتمع الدراسة فكان طلاب الدراسات العليا المقرر عليهم 
مادة هندسة البرمجيات. أخذت عيَّنة الدراسة من 34 مجتمعاً تجريبياً بشكل 
عشوائي» وُرٌعوا على مجموعتین متساویتین من 17 شخصاً» عرفت ك امجموعة 
آ٠‏ و«مجموعة با. تم تدريب جميع الطلاب بنفس الطريقةء وبناء على ذلك» 
كان لديهم نفس الخبرة والمعرفة. كان تصميم التجربة يتضمن عاملا واحدا 
(نموذج جودة الخطة) ومعالجتين (الخطة 5× والخطة 5)» ونظمت في تنفيذين 
تجريبيين (التنفيذ 1 والتنفيذ 2)» وأجريت على مدار يومين» بين الجدول 10 - 
1 تصميم التجربة. آما الجدولان 12-10 و13-10 فيلخصان النتائج التي تحقق 
صحة فعالية خطط القياس باستخدام إطار العمل متعدد العروض M۴‏ . 
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الحدول (10 -10) 
مقدمة عن الاختبارات الإحصائية 
E E‏ 


عامل واحد» معالجتان» تصميم Mann-Whitney Chi-2 t-Test‏ 
عشوائی تاماً 


عامل واحد» أكثر عن عمليتي ععالحة Kruskal-Waills Chi-2 ANOVA‏ 
أكثر من عامل واحد ANOVA‏ 


الحدول (10 11) 
تصمیم التجربة 


0 - 2 - 3 مخاطر ومهدداث الاستقصاء عن الصلاحية 


بالرجوع إلى الشكل 1-10 من النظرية إلى المشاهدة أو العكس» يتوجب 
على الباحث القيام بالعديد من الخطوات» خطوة لكل سهم؛ في كل خطوة»ء ثمة 
مخاطر تتعلق بتتائج الاستقصاء عن الصلاحية. كما في المرجع“» تم تقدیر بعض 
التفاصيل لقائمة من المخاطر الأساسية. يمكن الإطلاع على المزيد في المرجم؟'. 
يشير الاستقصاء عن صلاحية الاستنتاجات إلى العلاقة بين المعالجة 
والنتائج. المخاطرة المحتملة هتا هي عدم قیام الباحث برسم الاستنتاج الصحيح 
عن العلاقات بين المعالجة ونتيجة التجربة. في ما يأتي بعض المخاطر التي 
تنتمي إلى هذا الصف: 
# قوة إحصائية ضعيفة: قد يكشف الاختبار عن نمط في البيانات غير 
الصحيحة. 
8 افتراض منتهك للاختبار الإحصائي: استخدام الاختبار الإحصائي على 
البيانات التي تفتقر إلى المميزات التي تضمن التنفيذ الملائم. 
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# موثوقية المقاييس: إن استخدام آساليب قياس سيثة آو نموذج قياس 
سيئ قد ینتج بيانات سيئة. 


8 عناصر عشوائية فى الإعداد التجريبى: العناصر الخارجية (كالأحداث أو 
الظروف) يمكن أن تسبب تشويشاً للنتائج. 


8 عشوائية عدم تجانس المواد الدراسية: تعتمد النتائج على الفروقات 
الفردية أكثر من اعتمادها على المعالجات. 


الحدول (12-10) 
قیم المستوى م في اختبار رءد)اط2-۷: للجهد 


الثنفيذ 2 (المجموعة آ1 مقابل الملجموعة ب) 0.00002 رفض HoR®!‏ وقبول HRS!‏ 
الحدول (10- 13) 
قیم المستوى م في اختبار yعد‏ انط 2-۷د" للتعرض للخطا 


القيمة م للتعرض 


للخطا 
التنفيذ 1 (المجموعة ا مقابل المجموعة ب) 0.00721 رفض HoF®2‏ وقبول H,RS2‏ 
التنفيذ 2 (المجموعة أ مقابل المجموعة ب) 0.04938 رفض °2" وقبرل 8۴° 


تعنى الصلاحية الداخلية أيضاً بالعلاقة بين المعالجة والتتائج. قد يكون هناك 
مخاطرة من أن النتائج قد تشير إلى علاقة عرضية على الرغم من عدم وجود علاقة. 
في هته الحالة» من الأفضل تسمية المخاطرة بالتهديد. من التاحية التقنيةء التهديد 
هو حدث يتداخل مع تأليرات المعالجة وينتج علاقة سببية (سبب - تأثير) غير 
موجودة فعلياً. في ما يأتي بعض التفاصيل عن التهديدات التي تنتمي إلى هذه الفغة : 
# قد يحدث التاريخ عند تطبيق العديد من المعالجات على العيّنات تفسها 
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لأن سلوكهم يتأثر في أثناء المعالجة بتأثير المعالجات السابقة أو بتوليفة 
من المعالجات. 


الوقت. وقد ينتج تعديل السلوك من التعب آو الملل أو التعلم. إن إدارة هذه 
المخاطرة معقدة لأن أفراد العيّتة فى التجربة ينضجون بسرعات مختلفة. 
الاختبارات على الأفراد تفسهم» لأن افراد العيّنة يغيروك سلوكهم لأنهم 
# أجهزة وأدوات الاختبار هى ما قد يؤثر فى التسليمات والأدوات 
المستخدمة فى أثناء الاستقصاء. 
الاختيار هو تأثير التباين الطبيعي في الأداء البشري وكيف يمكن أن 
تتأئر النتائج باختيار الأفراد. قد يكون اختيار متطوعين أو اختيار أفضل 
عشر أفراد من تجربة سابقة أو اختيار أفضل خبير في موضوع ما أمراً 
# قد يحدث فناء عندما يتسرب بعض الأفراد من التجربة لأنهم لا يمثلون 
العيّنة التجريبية. 
# قد يحدث إسهاب أو تقليد عندما تتعلم مجموعة التحكم آو تقلد سلوك 
مجموعة الدراسة. 


8 قد تحدث منافسة تعويضية عندما ينفذ الفرد معالجات لا يكون راغباً 
بها لأن لديه حرافز ودوافع لتقليل أو عكس النتائج المتوقعة. 

# الإرباك الذي يسبب الاستياء بعكس النقطة السابقة. قد يتخلى الفرد 
الذي تُجرى عليه معالجات لا يكون راغباً بها عن المهمة ولا ينجز 
عمله بالكفاءة نفسها التى يعمل بھا عادة. 

تعنى صلاحية التركيب بالعلاقة بين النظرية والمشاهدة. تشير المخاطرة إلى 


ت 


المدى الذي يعكس فهي إعداد التجربة التركيب الذي سيتم اختباره فعلياً. 
المخاطر التي قد تنجم هي : المعالجة لا تعكس تركيب السبب جيداأء أو أن 
النتائج لا تعكس تأثير التركيب جيدا. قد ينتج ذلك من نقاط ضعف التحليل 
الإحصائي الذي يؤدي إلى علاقة سببية (السبب - التأثير) بين المعالجة والنتائج. 
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فى ما يي بعض التفاصيل عن المهددات التي تنتمى إلى هذه الفثة: 

#8 قد ينتج عدم كفاية التحليل المنطقي اللازم للتشغيل لتثركيب الدراسة 
عندما لا تكون التراكيب محددة بما فيه الكفاية لأنها تترجم على أنها 

# قد ينتج الانحياز الأحادي عندما يكون في الدراسة متخير مستقل واحد 
فقط أو حالة واحدة للدراسة أو فرد واحد للتنفيذ أو معالجة واحدة أو 
مقیاس واحد. فی هذه الحالةء قد پيکون الاستقصاء بدول ا 
التمثيل للتركيب لأنه لا يمكن إجراء تحقق متبادل لمتغير مستقل أو 
حالة أو فرد أو معالجة أو قياس مع الآخر. 


8 عوامل مربكة في ما يتعلق بمستويات العوامل التي قد تكون نتجت 
عندما لا يکون للعامل (أي التجربة) عدد محدد من المستويات لأن 
تأثير المعالجات قد يكشف عنها من قبل مستويات مختلفة لذلك 
العامل. على سبيل المثال» إن الفرق النسبي في التجربة هو بين سنتين 
إلى ثلاث سنوات» أو بين ثلاث سنوات إلى ست سنوات؛ في حين أن 
فترة من أربع سنوات إلى خمس سنوات من عمر التجربة ليس له تأثيرء 
لذا فإن مستويات العجربة يجب أن تكون 2»> 3ء 6 أو سنوات أكثر. 

سيكو من الخطاً تحديد مستويين ¿: أقل من آو يساوي 2» أو أكثر من 3. 

تعنى الصلاحية الخارجية بالتعميم. المخاطر المحتملة هي: خطا اختيار 

أفراد التجربة أو خطأً في تحديد البيئة والأداء أو توقيت خاطئ بحيث تتأثر 
النتائج بخصائص التجربة الأصاية التي تم تغييرها. في ما يلي بعض التفاصيل 

عن المهددات التي تتتمي إلى هذه الفة : 


قد يتم إنشاء مجتمع الدراسة عندما يكون الأفراد الذين اختيروا لإجراء 
اتجرية ا يداون مجتمع اللراسة. وهکذا فإنه من ء غير الممكن تعميم 


# قد يتم إنشاء الإعدادات عندما لا تكون الإعدادات آو المادة المستخدمة 
للنسخ الممائلة ممثلة للسياقء ما يجعل تعميم النتائج آمر غير منطقي. 

8 قل يتم إنشاء الفترة عندما تکون نتائج الدراسة متحيزة لفترة التشغيل 
الأمحددة., 
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0 - 2 - 4 إرشاداث توجيهية للتحربة 


عندما يكون تصميم التجربة ضعيفاًء لا تكون الاستنتاجات موثوقة؛ 
وغالباً ما لا تكون ملخصة من البيانات التجريبية. واجه العديد من الباحثين 
هله المشكلة عندما هدفوا إلى وضع إرشادات لتحسين تصميم وتصميم 

30+ 13« 18« 19“ 23“ 28“ 34“ 37“ 3( و , . 
الحاسمة للتجربة وإعطاء بعض الاقتراحات لكل منها. أما أهم مصادر 
الملاحظات التالية فھی المرجم* وخبرة المؤلف. 


يجب أن يتم تحديد سياق التجربة مقدماً» على وجه الخصوص. يجب 
تحديد الكوائن الضالعة في التجربة والخصائص والمقاييس اللازمة للتنفيذ 
لإضفاء الطابع الرسمي على توصيف السياق. على سبيل المثال» العوامل التي 
يمكن توصيفها هي: البيثة التي ينمَذ فيها المشروع (في المنزل أو شركة 
برمجيات مستقلة أو مجموعة عمل في الجامعة وغير ذلك)؛ وكفاءات وخبرات 
الموظفين الضالعين في المشروع؛ ونوع البرمجية المستخدمة (أدوات تصميم أو 
معالجات أو أدوات اختبار» وغير ذلك)ء وعملية البرمجة المستخدمة (عملية 
تطوير معيارية لشركة ماء أو عملية ضمان الجودة أو عملية إعداد وتهيئة» وغير 
ذلك). لسوء الحظ» يصعب تعريف العديد من متخيرات السياق فى عمليات 
البرمجيات. يجب إجراء الكثير من الأبحاث لتحسين قدراتنا التعريفية. إحدى 
الأمثلة ذات العلاقة في هذا السياق» ما أورده صمطمءطءن× وآخرون” الذي 
يبيّن الخطوط العريضة لتعريف عوامل توصيف السياق لصيانة برمجية. 


يجب آن يتم تحديد فرضية البحث/ الاستقصاء التي سيتم اختبارها بوضوح 
مقدماً. بصورة أدق» يجب أن تكون الفرضية مرتبطة بالنظرية الأساسية التي 
يجب التحقق من صحتها. عند عدم وجود هذا التتبع» فإن نتيجة البحث لن 
تسهم في توسيع نطاق المعرفة الحالي. في هندسة البرمجيات» غالباً ما تكون 
نتائج التجارب التي تهدف إلى إثبات الفرضيات نفسها متناقضة. إذا كانت 
الفرضية والنظرية غير قابلتين للتتبع» فإنه يصعب تفسير النتائج وتناقضهاء كما 
يصعب استخدامها. الفرضيات التي نشير إليها هي تأكيدات (تصريحات) يجب 
إثباتها من خلال تجربةء التي أشرنا لها مسبقاً بفرضية العدم/ الفرضية البديلة 
0/۳ . لتجنب الخلط» يستخدم بعض المؤلفين تعبیرات آخرى كاستقسارات 
الببحث/ الاستقصاء أو أهداف البحث/ الاستقصاء بدلا من فرضيات. على سبيل 
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المثال» التجربة التي تهدف إلى إثبات التوكيد الآتي ليس لها معنى: العدد 
السيكلوماتي لوحدة ما يرتبط بعدد الأخطاء الموجودة فيها. تشير بعض التجارب 
إلى أن عدد الأخطاء يقل كلما زاد العدد السيكلوماتي»ء وأن المتغيرين غير 
مرتبطین بعلاقة تبادلية. في حين أظهرت تجارب أخرى كيف أن عدد الأخطاء 
يقل بارتباط وثيق بين المتغيرين عتدما يقل العدد السيكلوماتي. لتفسير هذه 
النتيجة الأخيرةء تم افتراض أنه عندما يكون العدد السيكلوماتي کبیراًء فان 
المطرّرين يولون اهتماماً أكبر بالبرمجة» وبناء على ذلك تكون الأخطاء الناتجة 
أقل. هذه المعرفة غير مدعومة بدليل تجريبي في تطوير هندسة البرمجيات. 
يمكن تقديم تفسير أفضل إذا رجعنا إلى نظرية بارتز؛ إن الارتباط بين درجة 
التعقيد السيكلوماتى" لوحدة ما والأخطاء المعرفة يجب أ يرتبط بكفاءة 
الجهد الذي يجب أن يتحمله المطزر لفهم محتويات الوحدة وسلوكها. 


يجب آن يتم تحديد تصميم التجربة بحيث يكون آفراد العيَّنة التجريبية 
وأدوات التجربة ممشلين لسياق الاستقصاء. إضافة إلى ذلك يجب أن يحدد 
مقدماً كيف سيتم اختيار آفراد العيّنة التجريبية وكيف سيخضعون لكل معالجة. 
يجب أن يكون المخطط الناتج من التصميم قادرا على الحد ما أمكن من 
الأسباب التي قد تؤدي إلى وجود تهديدات لنتائج التجربة أو التوقع بكيفية 
قياس تأثيرها في التتائج. عند تحديد التصميم التجريبي» يجب أن يتم توضيح 
إذا ما وجدت فروقات بين عيّنات التجربة والوحدة التجريبية. فإن وجدت 
فروقات» وَجَبَّ تتبع الأفراد والوحدة مع بعضهما البعض. غالباً ما يخلط 
القائمون على التجربة بينهماء لذاء إذا كان لابد من توزيع استبيانات» يجب أن 
يشير التصميم التجريبي إلى أن آفراد العيّنة التجريبية هم آولئك الذين سيجيبون 
عن الاستبيانات» في حين أن الوحدات التجريبية هي المؤسسات التي تتم فيها 
المقابلات لجمع بيانات التجربة. 

تتضمن كل وحدة العديد من العيّنات التجريبية. عند تصميم تجربة» من 
المفيد اعتماد مخططات معروفة فى الأدبيات التى اعتمدت ودعمت فى الأدلة. 
وهذا سيجنب التجربة المخاطر عديمة الفائدة والحد من التهديدات التي تؤثر 


(8) مقياس أو مؤشر مكاب (رااعاوصه) M١٥‏ أو مايعرف بدرجة التعقيد السيكلوماقي 
Complexity)‏ omatieاCye)‏ هو مقیاس أو قيمة يعكن من خلالها قياس درجة تعقيد برنامج أو خوارزمية معينة. 
تم تطوير هذا المقياس من قبل وماس ج. ماكابي عام 1976 (المترجم). 
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في صلاحية النتائج. إضافة إلى ذلك» يجب آن يتم توقع مستويات التحكم 
الملائمة لتجنب أن تؤثر توقعات المشاركين والباحث الذي يجري الاختبار في 
النتائج بطريقة أو بأخرى. في التجربة» يجب أن تكون المتغيرات المستقلة 
معرّفة بوضوح وذات دوافع مع كيفية تحليل البيانات المرتبطة, إضافة إلى ذلك؛ 
يجب أن يكون نطاق المتغيرات المستقلة والتحليلات الإحصائية مناسبة» 
وتتجنب التعارضات المفاهيمية؛ وبخلاف ذلك قد بؤدي تفسير النتائج إلى 
التباس. أخيرآً» عند تصميم تجربة» من الأفضل تجنب التحكم بسلوك أفراد 
عينة التجربة. بمعنى أدق» يجب أن لا يشعر أفراد العيَنة أنهم مراقبون أو مسيطر 
عليهم» خصوصاً في مشروع الاستقصاء. في هذه الحالةء قد يتأثر الأفراد 
بسلوكهم عندما يعرفون أنه مسيطر عليهم» وقد يتصرفون بطريقة مختلفة عن 
تصرفهم في الظروف الطبيعية. لذاء على سبيل المثال» من الأهمية بمكان عدم 
تعديل المقاييس المألوفة وجمعها على أساس منتظم. ينصح باستخدام المقاييس 
التى يمكن جمعها على المنتجات من دون معرفة المطررين بهاء أو استخدامها 
لدعم العمليات القادرة على توفير معلومات حول العمليات المختبرة . لكنء 
ليست تلك هي الحالة التي تأخذ في الاعتبار النتائج التجريبية كتقنية لتقييم آداء 
المطزّر. 

يجب أن تكون البيانات التي يجب جمعها موضوعية ومحددة. أما البيانات 
غير الموضوعية فيجب أن يتم تحديدها بدقة شديدة وذلك لتقليل درجات 
الحرية لدى من يجري القياس. إضافة إلى ذلك يجب أن يتم تحديد وسائل 
الجمع والتحكم بدقة آيضاً. 

يجب أن يحدد عرض وتفسير النتائج الكيفية التي رسم بها الباحث 
استنتاجاته والسماح للقراء المهتمين التحقق منها. يوضح المرجع* إرشادات 
لإنتاج تقارير عن نتائج التجربة ويدرج العديد من المراجع التي تفصل القضايا 
التي تواجه عملية نشر النتائج. حالما يتم بيان استنتاجات التجربةء يجب آن يتم 
توفير وثائق مناسبة تصف التجربة بحيث تكون قابلة لنقلها إلى باحثين آخرين. 
لهذا الغرض» تقدم أدبيات الاستقصاء اقتراحات متنوعة* . في ما يلي 
بعض الإرشادات الموجزة عن إنتاج الوثائق التي تكون حزمة الاستقصاء: 

# الوصف التفصيلي للمعالجات بما في ذلك كافة أنواع التعليمات 

والأدوات التي تدعم التنفيذ. 
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العناصر التجريبية التي تطبق عليها المعالجة؛ على سبيل المثالء 
الشيفرة البرمجية وتصميم البرمجية أو مواصفاتها. 

8 تعليمات لوصف السلوك الدقيق للجهات المعنية في الاستقصاء» بما 
في ذلك الباحثون. 


تفاصيل الدراسات التجريبية أو تجارب المحاولات. 

آليات لجمع البيانات التجريبية والتحكم بهاء سواء كانت مؤتمتة أو يدوية. 
# المواد التعليمية لإعداد أفراد المجتمع التجريبي للاستقصاء. 

البيانات الخام التي جمعت في التجربة الأصلية » عندما يكون ذلك ممكناً. 

الوصف والمقاييس وأساليب جممع كفاءات وقدرات آفراد المجتمع 


التجريبي وتحديد خصائص ذلك المجتمع والأفراد المختارين الذين 


قوة النسخ المتمائلء وفقاً للعيوب التي تضمنتها التجربة الأصلية 
والنسخ الأخرىء من حیٹ عغدد وآنواع أفراد المجتمم التجريبي 
والتحكم بالبيانات أو التحليل الإحصائي لتنفيذ التجربة على البيانات 
الأساس المنطقي لعملية صنع القرار في أثناء تصميم وتنفيذ التجربة› 
وذلك بهدف تجنب أن تغفل النسخ المتماثلة عن أي جوانب مهمة. 

LL‏ تقییم تکلفة الاستقصاء. 

# تحليل التكاليف - المنفعة في ما يتعلق بتطبيق النتائج وفقاً لقيمتها 
بالنسبة إلى المعنيين بالمشروع. 


0 - 3 الدراسات التجريبية لعلم هندسة البرمجيات 


0 - 3 - 1 لمحة عامة 


الواقع» تستخدم هندسة البرمجيات في كافة العلوم سواء كانت علوم طبيعية أو 
هندسية أو اجتماعية. تعنى هندسة البرمجيات 7 بالتطوير من المشكلة المشاهدة 
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التي تؤدي إلى تأثير سلبي أو تأثير غير مرغوب به وتتبع مسارين بديلين ينفذهما 
الباحثون. في الحالة الأولى (الشكل 10 - 6) يعرف الباحث نظرية» ويجعلها نافذة 
المفعول من خلال الأساليب والعمليات والمنهجيات الموضحة كتقنيات مبتكرة 
ويتحقق منها لإثبات إذا كانت تحل المشكلة. فإذا كانت كذلك» يتم قبول النظرية 
والتقنيات» وبخلاف ذلك» يتم تعديل النظربة و/أو التقنيات ويستمر الاختبار 
العلمي. بدلا من ذلك (الشكل 10 - 7)» يحدد الباحث تقنيات مبتكرة جديدة هع 
الشك في كون التقنيات الجديدة فاعلة في حل المشكلة. يتبع الاختبارات العلمية 
في حال الحصول على نتائج إبجابية قبول التقنيات وتلخص نتائج الاختبارات في 
نظرية. وإلاء فإن النظرية يتم تعديلها والتحقق منها مرة أخرى. على سبيل المثال» 
المعلومات المخفية تكون قائمة على النظرية» لكن الاستقصاء التجريبي ضروري 
للتحقق من صحة التقنيات التي تجعل منها معلومات تشغيلية في عمليات تطوير 
ال مجیات؛ ویستخدم النمو فج کائني التو +4 object-oriented paradigm)‏ نجاح 
كتقنية تسمح لنا بتطوير برمجية ذات جودة عالية مقارنة بنماذج أخرى. مرة أخرى» 
التحقق من كفاءة نموذج 00 تجريبياً غير كافي» وكذلك نظرية التلخيص التي 
لا تزال مفقودة. 


الشكل (6-10): تجميع التكنولوجيا 
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هندسة البرمجيات وممارساتها هي عمليات محورها العامل البشري. لذاء 
تعتمد فعاليتها على عوامل التعقيد كالدوافع والخبرة. تعتمد فعالية الممارسات 
على هذه العوامل وهذه صعبة الفهم كما يصعب التحكم بها. نتيجة لذلكء لا 
يمكن أن تكون العلاقة بين تطبيقها وتأثير المنتج والعملية قطعية. يمكن تقييم 
مثل هذه العلاقات تجريبياً*. قد تعتمد نتائج الاستقصاء التجريبي على سلوك 
مواضيع الدراسة التجريبية والمميزات العديدة التي قد تفترضها نفس المشكلة 
بسياقات مختلفة ومن المتغيرات العديدة التي تكون ضمنية وغير مسيطر عليها. 

تشير مظاهر الاستقصاءات التجريبية إلى الحاجة إلى عمل نسخ ممائلة. 
لذاء تتطلب هندسة البرمجيات أيضاً أن تكون النتائج التجريبية قابلة للنسخ من 
قبل أطراف خارجية» اتساقاً مع الفكر العلمي الحديث. في المرجع» بشير 
المؤلفون إلى أن استخدام التجارب الدقيقة التي يمكن إعادتها هو «السمة 
المميزة للمعرفة العلمية أو الهندسية). يهدف النسخ المتماثل في هندسة 
البرمجيات إلى ضمان أن العلاقة بين الابتكار والمشكلات التي بحلها والنظرية 
التي تعزز هذه العلاقة سارية المفعول»ء هذا من ناحية؛ ومن ناحية أخرى» 
يهدف إلى تعميم المعرفة التي تأخذ في الاعتبار التغيير الكبير في الظروف 
التجريبية الصريحة والضمنية. 


الشكل (7-10): تجميع النظرية 


334 


0 3 - 2 تكرار الاسنقصاء التجريبي 


في عمليات الاستقصاءء التي ينفذها الآخرونء من المهم التأكد من «عدم 
حصول أخطاء غير مقصودة أو مقصودة . يمكن أن يساعد التكرار في قناع 
المساهمين المحتملين بفاعلية تبتي ابتكار ما تدعمه نظرية. يمكن الحصول على 
نتائج تجريبية ذات أهمية مثيرةء على الرغم من أن الحصول على التتائج نفسها 
في الكشثير من الحالات يمكن أن يكون أكثر إقناعاً وبالتالي أكثر قبولا. إن 
عمليات الاستقصاء المتكررة التي يٿم ! إجراؤها في حالات مختلفة» الي نو تژؤكد 
نتائج الدراسة الأصلية والفرضية التي يتم على أساسها التجريب» هي من الطرق 
التي يتم من خلالها جمع الأدلة. في عمليات التكرار» يجب على الباحث أن 
يتحكم في المخاطر التي قد تنتج من التجارب في عمليات التحقق. في 
الحقيقة» يمكن أن تكون نتيجة عمليات التكرار مختلفة عن نتيجة التجربة 
الأصلية بسبب عدم وجود سيطرة كافية على المخاطر. على سبيل المثال» في 
تجربة أجراها شتايدمان («صaصەلنە«ط8)‏ وآخرون حول مدى فائدة الرسم 
البياني» استنتج أن الرسوم البيانية غير مفيدة في تمثيل الخوارزميات. تم تنفيذ 
عملیات ال ار لهذه التجربة بواسطة سكانلان (صعاههء8)#» وقد حدد الخلل 

في التجربة السابقة على أنه: لم يكن الزمن المخصص لموضوع الدراسة أحد 
عوامل التجربة الأصلية. كان بإمكانهم أن يستغلوا جميع الوقت الذي يحتاجونهء 
وآن يستخدموا أي طريقة في عملية التمثيل. ایر ۱ المؤلف آنه يمكن توفير 
الوقت عن طريق استخدام الرسوم البيانية". تم إثبات ذلك لأن الوقت 
المسموح كان محددا. إذاً عن طريق إعطاء الفترة الزمنية نفسهاء حصل أفراد 
التجربة الذين استخدموا الرسوم البيانية لوصف الخوارزميات على نتائج مكتملة 
بشكل أكبر من الطرق الأخرى. فى هذه الحالةء تآثرت التجربة الأصلية 
بمخاطرة صلاحية البناء. ٠‏ 


في عمليات تكرار الاستقصاء» من المهم أن يقوم الباحث بتحديد مقادير 
التكاليف والمنافع حسب آدوات جمع البيانات. هذه الأدوات مهمة من أجل 
الحصول على تحليل التكلفة - المنفعة للاستقصاءء الذي يمكن أن يكون مفيداً 
لتكرارات التحقق الأخرى التي سيتم تنفيذها على التجربة. يمكن ملاحظة آنه 
ينتج من التكرار معلومات مفيدة حول التكلفة والغوائدء وبالتالي زيادة الموثوقية 
حيث تصبح عنصرأً فاعلا لتكرارات إضافية. 
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لسوء الحظء هناك الكثير من الجوانب التي تجعل من الصعب توفير 
ظروف التجربة الأصلية نفسها في عملية التكرار. وهذه العوامل هي: أولاًء 
يوجد الكثير من المتغيرات التي تصف سياق الاستقصاءء كما تم ذكره سابقاً. 
يمكن أن تتغير هذه العرامل مع الوقت إذا تم إعادة التجربة اراق نفسه» أو 
يمكن أن تتغير العوامل أيضاً إذا تغيرت الع موضوع الدراسة نفسها. ثانياًء 
عادة يتم تنفيذ التكرار لاختبار ما على عيّنات اختبار مختلفة عن العينات 
الأصلية آو السابقة. لذلك» يمكن أن ينتج من التكرار نتيجة تختلف عن 
النتيجة الأصلية وعن نتائج اختبارات أخرى» نتيجة لاختلاف تخصصات 
وخبرات العيّنة وليس نتيجة طريقة الإجراء. على سبيل المثال» تخيّل آن 
المطوّر بخبراته يستطيع أن يحسن الإنتاجية ست مرات. إذا كانت العيّنات 
التجريبية التي تكرر عليها الدراسة أكثر خبرة من العيّنة الأصلية للتجربةء 
يمكن أن تكون النتائج إيجابية» لكن قد تؤثر خبراتهم في النتائج أكثر من 
تأثير طريقة المعالجة. يضيف هذا الجانب الثاني صعوبة إضافية ل تقیید 
عوامل التكرار: قد تختلف توقعات العيّنات التى تجری عليها عمليات الإعادة 
عن توقعات العيّنة الأصلية التى أجريت عليها الدراسة. يمكن لاختلاف 
التوقعات هذا أن يؤثر في النتائج. 

إن الهدف من الإعادة التي تحصل على نتائج تتوافق مع النتائج الأولية 
هو تأكيد النتائج الأصلية. إذا كانت نتائج الدراسة الأصلية إيجابية وفقاً 
لفرضية ا تعزز الإعادة هذا النجاحء وإذا كانت نتيجة الدراسة الأصلية 
سلبية» تعزز الإعادة هذا الفشل. وفي المقابلء الإعادة التي تؤدي إلى نتائج 
تختلف عن نتائج الدراسة الأصلية تحفز لإجراء عمليات تحليل إضافية تهدف 
إلى تحديد الأخطاء في تصميم وتنفيذ التجربة. من أجل تقييد عوامل عمليات 
الإعادة كجزء من عملية تسمى محفزات الاختبار™» يجب إعداد مجموعة 

من الوثائق المناسبة التي تصف التجربة الأصلية. تضمن هذه الوثائق وجود دقة 
كافية في عمليات الإعادة. لذلك» عندما ينتج من عملية إعادة أو أكثر نتائج 
تدحض نتائج الدراسة الأصليةء يمكن أن يعتمد الباحث آحد الخیارین. إذا تم 
تأكيد فاعلية الابتكار عن طريق الدلائلء يجب تعزيز النظرية موضع الدراسة 
قبل قبولها. تعزيز النظرية يعني تعديل أهداف الاختبار آو المسببات آو النتائج أو 
کلیهما. 


نتيجة لذلك» تختلف متغيرات وتصميم الاختبار الأصلي» بعد تنفيذ 
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تخييرات على الاختبار الأصلي» إذا كانت النتائج تتوافق مع توقعات منفذ 
الاختبار» يتم إعادة الاختبار لتأكيد النتائج. في الحالة الثانيةء إذا لم تبت 
فاعلية الابتكار»ء يجب على الباحث أن يأخذ بالحسبان أنه يجب تعديل الابتكار 
أو النظرية وفقاً للنعا ئج التي تم الحصول عليها في التجربة وفي عمليات 
الإعادة. في الحالتين» يجب تعديل الاختبارات الأصلية وتنفيذها مرة أخرى. 
عند الحصول على نتائج ناجحة» يجب إعادتها لتأكيد النتائج. في الحالة 
الأولى تتبع النظرية الابتكار» بينما في الحالة الثانية يتبع الابتكار النظرية. 


من أجل إتمام العملء من المهم تحديد عدد التكرارات المثالية من أجل 
إعداد مجموعة مناسبة من الأدلة. في حالة التجارب التي يتم التحكم بها 
يمكن أن نرجع إلى العوامل الإحصائية ™. في جميع حالات الاختبار 
الأخرى» من المهم اعتماد خطة موجهة من أجل تحديد العدد المناسب من 
التكرارات لاختبار ما. يمتلك الاختبار الأصلى أهمية معيّنةء للإعادة الثانية 
أهمية أكبر لأنها تؤكد نتائج الدراسة الأصليةء لاإعادة الثالثة آهمية في زيادة 
عدد الأدلة على نتائج الدراسة. كلما أصبح عدد الأدلة أكبر» تقل أهمية إجراء 
تكرارات آخرى. عندما يصبح عدد الأدلة كافياًء تقل أهمية التكرار أكثر فأكثرء 
بحيث لا تعود ضرورية. 


0 - 3 - 3 الاستقصاءات التحريبية بة لنتاج المعرفة 


تتطلب إعادة استخدام النتاة ئج التجريبية فعلياً أن يتم تلخيصها وتنظيمها 
بصورة معرفة يمكن للمهتمين بالنتائج فهمها. ي يجب أن تكون هذه المعرفة قابلة 
للاستخدام من دون الرجوع إلى الباحث الذي قام بإعدادها. كذلك» يجب أن 
تكون قابلة للتطبيق في أحوال مختلفة» وفي الوقت نفسه مصممة للاستخدام في 
حالة معيّنة” . للحصول على هذا الهدف» يجب إعداد مكونات المعرفة التى 
تم تحدیدها في الفقرة السابقة. وأكثر من ذلك» يجب أن تحتوي المجموعة 
المعرفية على جميع المعلومات المهمة لتحديد مدى تشابه أو اختلاف الحالة 
التي تتم فيها الإعادة عن الحالة الأصلية. 


تعزى الاعتبارات التي تم ذكرها إلى دور الاستقصاءات التي تتم في البيئة 
الحيوية لإعادة استخدام النتائج التجريبية» التي تعيد التجربة الأصلية بشكل 
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الدراسة الأصلية ومجموعة الأدلة عليها. لتحقيق هذا الهدف» قام باسيلي 
ناوه" بتوفير مخطط تنظيمي لجمع الخبرات حول إعادة استخدام النتائج 
التجريبية» من أجل تحليلها وإنشاء مجموعة معرفية حولها. يعرف المخطط 
باسم معمل الخبرة EF )Experience Factory)‏ ويعمل على جمع الخبرات 
وعمليات الاستقصاء التجريبية للمعلومات المرتبطة فى عميات التطوير فى عدة 
مجالات: التكلفة والفوائد والمخاطر ومبادرات التطوير. من أجل التوضيح› 
يصف الشكل 8-10 مخطط معمل الخبرة بشكل مختصر. يمكن الحصول على 
تفاصيل إضافية في المرجعين"' و" على الرغم من اختلاف المخطط بشكل 
بسيط. حالما يبدأ المشروع» ويتم تحديد الأهداف» يتم تحديد مصادر وحالات 
المشروع. تجعلنا هذه المعلومات قادرين على استخراج ملفات الخبرات المتوافرة 
من قاعدة الخبرات» التي تتضمن المنتجات والدروس المستفادة والتماذج. بوچود 
أو عدم وجود دعم يقوم مدير المشروع بتحديد العمليات التي ينوي استخدامها 
ويستنتج الخطط التنفيذية للمشروع منها. خلال تنفيذ المشروع؛ يتم تسجيل 
البيانات التي يجمعها المحلل في قاعدة بيانات المشروع. يتم موالقتها من أجل 
البحث عن ملفات خبرات آخرى يمكن آن تسهم في تطوير تنفيذ المشروع بما 
يتناسب مع أهدافه. في نهاية المشروع» يتم مقارنة البيانات التي تم جمعها 
بملفات الخبرات الحالية ويتم إضافتها وفق الأصول لتوفير مجموعات تحقق 
إضافية أو لتنقيح محتواها. بعد إنجاز المشروع» يمكن إضافة الدلائل التجريبية 
الجديدة إلى الموجودة في قاعدة بيانات الخبرات» وبالتالي تعميم أكبر للمعرفة. 
بهذه الطريقة تصبح قاعدة الخبرات توفر المعرفة بشكل أعم. 


من أجل استخراج المعرفة للنتائج التجريبية» يمكن اعتبار التكرارات التي 
تشکل ما یسمی عائلات الجار ب 2 تكرر كل تجربة في العائلة تجربة آخرى 
في العائلة نفسهاء مع تعديل في متغيرات السلا عطلب فلك إطار عمل بورح 
النماذج المختلفة والمستخدمة في التحقيقات للعائلة» وقادراً على تو 
القرارات المتخذة خلال التصميم. يجب أن يعطينا الإطار القدرة على تحديد 
محور الاختبار الذي يجب أن يبقى بلا تغيير هو والعوامل التي تتغير مع كل 
دراسة في العائلة بحيث يمكن تعميم النتائج في نظرية موحدة توضح جميع 
آهداف الببحث في هذا المشروع. 


يشير إطار الحمل في هذا الفصل إلى مقاييس السؤال المستهدف )60M(‏ 


38 


التي اقترحها کل من بايسیلي ان8 ورومباش ط۳٥۸‏ وتم تکییفها لتحدد 
آهداف س بشکل ا في ما ڀآتي تقایل حول إطار العمل الذي تم 
٠‏ يتم تحليد حداف البحث عن طريق خمسة عوامل متغيرء 


2. الغرض: لتمييز/ اكتشاف (ما هي؟)ء تقييم (هل هي جيدة؟)» التوقع 
(هل يمكن أن أقيّم شيا في المستقبل؟)ء التحكم (هل يمكن أن اتلاعب في 
الأحداث؟)» التطوير (هل يمكنني أن أطور الأحداث؟). 

3. التركيز: النموذج الذي يهدف إلى عرض نواحي هدف الدراسة المعنية - 
على سبيل المثالء التأثير في مدى موثوقية المنتج» تحديد الخلل/ منعه» وقدرات 
العملية/ دقة نموذج التكاليف. 


4. وجهة النظر: ما هي نواحي التأثير التي نريد أن نحصل عليها؟ على 
سبيل المثال» وجهة نظر الباحث الذي يحاول الحصول على بعض المعلومات 
حول النقطة المهمة. 

5 السياق: النماذج التي تهدف إلى وصف البيثة التي تم فيها أخذ 
القياسات (على سبيل المثالء الطلاب/ المشاركون» المبتدئون/ الخبراء» فى 
البيئة الحيوية/ في المختبر؛ المشاريع يجب تنفيذها في أثناء الاختبار/ مشاريع تم 
تنفيذها بالفعل). 

لتوضيح عوامل آهداف البحث بصورة أفضل»ء يجب التصريح عن القيم 
التي تم افتراضها في الاختبار. يمكن أن يكون هدف الدراسة عملية تتطلب 
كفاءات تقنية لإجراء مهمات معيّنة (تقنيات)ء أو عملية تصف كيفية إدارة 
تقنيات التطبيق للحصول على هدف ما (أسلوب)» أو عملية تصف التطور 
الكلي لبرنامج ما (دورة الحياة). إن الهدف العام للاختبار هو تقييم شيء ما. 
يريد الباحث دراسة تقنية ما وتقييم تأثيرها في مرحلة التطوير. أكثر وجهات 
النظر تكراراً هي وجهة نظر الباحث أو معد ملف المعلومات. عادة ما يتضمن 
اختبار المشروع وجهات نظر المدراء والمهتمين بتقييم أثر التقنية في الجهد 
المبذول والمواعيد الزمنية والعائد من الاستثمار. عندما يكون هدف الدراسة 
تقنية ما» غالباً ما يكون التركيز منصباً على تقييم أثر التقنية في مكزنات 
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برمجية واحدة أو أكثرء» سواء كانت عملية آو منشح آو مبرمجون. بتضمن 
سياق البحث عوامل بيئية متعددة. پمكن إجراء الدراسات على طلاب أو 
خيراء» بوجود أو يعدم وجود قيود على الفثرة الزمنيةء في مجالات التطبيق 
المعروفة أو التي لم درس بعد. 


المسار 


الشكل (8-10): معمل البرة 


يمكن أن يتضمن هدف استقصاء ما على عدة عوامل؛ في هذه الحالةء 
يجب تصميم الدراسة الجيدة لكل مجموعة من القيم التي پمكن أن تنتجها 
العوامل. إضافة إلى ذلكء يتم ربط كل دراسة بهدف محدد. وفقاً لذلك» تكون 
مهمة الباحث جمع نتائج كل دراسة وتعميمها بحيث يمكن استخراج المعلومات 
هن عائلة الشجارب. 

هذا مثال على عائلة ما: يتضمن هدف الدراسة أسلوبين لصيانة النماڈج 
(إصلاح سرپع (QF) (Quick Fi)‏ وتحسین تٹکرlري (Iterative Enhancement)‏ 
(۲۴))؛ الهدف هو تقييم الفرق بين الطریقتین Q۴‏ و امع التركيز على تقييم 
تأثیر هذه الطرق في مجموعة من الخصائص و4 Q2, Q3,‏ ,101؛ من وجهة نظر 
مدى فاعلية تأثير العملية في مجموعة الحالات ع×10. إن × هو المتغير الذي 
يجعل من الهدف السابق عائلة من العوامل. لهذه النقطة» يجب تفصيل القيم 
التي يتم افتراضها. 
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س1: التصحيح 

مجموعة المكرّنات المعدلة: M€8‏ 
مجموعة المكوّنات المتوقعة: ٤8‏ 
مجموعة المكرنات الصحيحة : ٥€S‏ 
التصحيح : COR = # (CCS‏ 

س2: الإتمام 


COM = # (MCS :plaتll‎ 


س3: تعديل الخطة الزمنية 

الزمن اللازم لتصميم التعديل : sءل1‏ 

الزمن اللازم لبرمجة التعديل المصمم: له 

الزمن اللازم لإجراء عمليات الإصلاح: ل۲0 + T = Tes‏ 
س 4: القابلية على التت 

# آفراد العيّنة التجريبية التي يمكن تتبعها بشكل محمي: 8× 
# أفراد العيّنة التجريبية: ×١‏ 

القابلية على التتبع : 100 * ۸9/۸ = 1۸ 


1 طلاب الجامعات (.0«.5) الذين يتعاملون مع تأثير التعديل ذي 
المستوى المتخفض. 

2: طلاب الجامعات (.0«.51) الذين يتعاملون مع تأثير التعديل ذي 
المستوى المرتفع. 

3 المحترفون )۶۴١۵‏ الذين يتعاملون مع تأثير التعديل ذي المستوى 
المتخفض. 

4: المحترفون )۶۳١۵‏ الذين يتعاملون مع تأثير التعديل ذي المستوى 
المرتفع. 
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لأسباب تتعلق بالمساحة»ء لن يتم توفير وصف عملية التجربة وتنفيذها. 
يبيّن الجدول 14-10 ملخصاً للنتائج. من أجل التوضيح» بإعطاء نموذج معيّن 
مثل ۴ء تظهر الإشارة ٩+‏ قبل النموذج إذا كائت قيمته أكبر من قيمة المنافس 
له» أما إشارة «++» فتشير إلى زيادة ملحوظة في قيمته بالنسبة إلى النموذج 
المنافس له في الدراسة قيد البحث. 

تلخيصاً للنتيجة» يعبر عن كفاءة نموذج الصيانة بالرمز 1ء ويتم التعبير عن 
الفاعلية عن طريق مجموعة آخرى من عوامل الجودة التي يتم قياسها. لذنك» 
المعرفة التي يمكن تلخيصها عن طريق تحليل التتائج المبيّنة في الجدول 14-10 
هي : 18 أكثر كفاءة من ۰Q۴‏ 1۴ بشكل عام أكثر فاعلية من Q۴‏ عند مقارنة 
التعديلات الطفيفة. لكن»ء ثمة خطورة عالية في عمليات التتبع» لذلك من 
الأرجح أن ينتج منها انخفاض في نوعية التطبيق البرمجي. هذه المعرفة التجريبية 
تدحض الدلائل السابقة والتي هي» وفقاً للمطرّرین» ۴ أكثر كفاءة من 1۴. 

تشير التتائج أيضاً إلى أن الاستدلال يهمل الكفاءة المنخفضة ل ۴@ في ما 
يتعلق بضمان جودة النظام البرمجي. إضافة إلى ذلك؛ تشير الخبرة إلى أن 
نموذج الصيانة يكون أكثر كفاءة عند تطبیق 1۴ على المحترفين عنها عند تطبيقها 
على الطلاب. أخیراًء تشیر الدلائل أن Q۴‏ تكون أكثر كقاءة فقط عندما يكون 
تأثير التعديل طفيفاً. 


الحدول (10- 14) 
ملخص نتاثج التجربة 
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0 - 4 الاستقصاء التجريبي لقبول الابتكار 


كول الإنسان هو محور هندسة البرمجيات» يمكن عرض الابتكار ونشره 
من خلال عمليات حقيقية إذا تم قبول هذا الابتكار من قبل المطورين 
المسؤولين عن العمليات. يمكن توقع النظرية الآتية: المعرفة التي يمكن آن 
يوفرها الابتكار ويفيد بها عملية تطوير البرمجيات هي شيء ضروري؛ على 
الرغم من أنها ليست كافية للابتكار الذي سيقبل به المطرّرون»ء لأنها تعتمد على 
عوامل اجتماعية واقتصادية لعملية التجريب. القبول هو العامل الأساسي لتعميم 
الابتكار وبالتالي وجود طلب عليه. لأخذ النظرية السابقة بالاعتبار» من المفيد 
مشاركة المطورين الذين سيقومون بشكل مؤكد بالتعامل مع الابتكار كعينة 
تجريبية. النتيجة المتوقعة هي أن يستوعب المشاركون المعرفة الجديدة» وبالتالي 
يقوموا بتعميمها وجعلها صالحة للئشر. 

استخدم المؤلف خبرته في تنفیذ ۴1 في الشركات لتأكيد النظرية السابقة. 
في هذا الفصل»ء ولغايات تتعاق بالمساحة» لم يتم سرد التفاصيل. ولكن» 
يمكن أن يطالع القراء المهتمين المرجعين“ و“ كمراجع للخبرات المطلوبةء 
التي قد تكون مفيدة للباحثين الآخرين حول اختيار طرق الاختبار المناسبة أو 
حول تأكيد النظرية السابقة. 


تم ته نيق كل دراسة تم تحليلها حسب واحدة من الفثات التي تم سردها 
وتصنيفها وفقاً لعوامل تنظيمية وتقنية» تم وصف ذلك في جدول 15-10 في 
تدریج مرتب (8 = مرتفع» ا = منخفض). يظهر الجدول 16-10 نتائج عملیات 
التجريب. هذا ویمکن اعتبار أمور أخرى. 


في الاستقصاء بأثر رجعي» تم إشراك المطؤرين الذين شاركوا في البرامج 
المنفذة كأفراد في العيّنة التجريبية من دون إدراكهم. بهذه الطريقة فقط يمكنهم 
تعلم ومشاركة الأمور السليمة المستخدمة مع تفسيراتها؛ آي إنهم يدركون فرائد 
الابتكار. لكن نظراً إلى أنه لا يتم إشراكهم في استخدام المشروع» لذا فإن أحد 
الشروط الأساسية لعملية القبول غير متوافر. استراتيجية الاختبار هذه ووفقا 
للنظرية التي تم ذكرها سابقاً» لا تفرض شروطا لقبول الابتكار. تؤكد الخبرة 
التجريبية هذا النقص: جميع المطؤرين بمن فيهم أولئك الذين قاموا بتنفيذ 
المشروع» لا يستوعبون الابتكار. 
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متغيرات | الاستثمار 
العامل 
التنظيمي 
المائثدعل 
الاستشمار 
MANAG Imp‏ 


الحدول (15-10) 
عوامل التوصيف 


ما تستشمره الشركة لتقديم 
الابتكار 


العائد على الاستثمار الذي 
تحصله الشركة بعد تقديم 
الاہتکار. 

ا لتحسینات المتصورة فن قبل 
الإدارة. 


التتحسين المنصور عن الفريق 
التقني باستخدام التقنية 
الحديدة. 

الصمعوبة التي يواجهها 
البتكرون لشحديد نموذج 


الحودة المستخدم لتقييم فعالية 
وكفاءة الابتكار. 


الصعوبة التي يواجهها 
السامون في قبول نموذج 
الحودة المستخدم لتقييم فعالية 
وكغاءة الابتكار. 


مرتفع (8)» عندما يحدث نق التكئولوجيا 
خلال أكثر من 6 أشهر. من الصعب التوقع 
بتأثير الابتكار في عمليات الإنتاج في الشركة. 

مرتفع (81) عندما پکون مقداره أکبر بثلاث 
رات من الاستشمار في غضون عامين على 
الأقل. 

تقييم ذاقي معبر عه من خلال اعتبارات 
شخصية وإجابات يشم تحصيلها من خلال 
المقابلات أو الاستبيانات. 

وإجاباث يشم الحصول عليهاعن خلال 
المقابلات والاستبيانات. 

مرتفع (8) عند إصدار ثلائة إصدارات كبرى 
من تموذج الجودة على الأقل في أثناء 
الاستقصاء قبل ا لحصول على الإصدار الأخير. 


مرتفع (8) عند عقد ثلائة اجشماعات كبرى 
يدعو لها ا سامون للحصول على مزيد من 
التوضيح عن نموذج الحودة وتطبيقاته. 


يتم تقييم استقصاء المشروع وفقاً لنوع الاستقصاء. في حالة الاستقصاء؛ 
يتعلم المطوؤرون استخدام الابتكار لكن نادراً ما يكونون مقتنعين بفوائده» على 
الرغم من آنه يكون موافقاً على التدابير المتخذة والتفسيرات التي تم الحصول 
عليها. وفقاً للمؤلف» يعود سبب ذلك إلى أن المطرّر يرى تصميم التجربة كما 
لو أنه فرض عليهء ولا يشعر أنه مشارك فيه. للاستقصاءات الميدانية عدة 
متغيرات: عادة ما يتم تقييم الاستقصاء التجريبي خلال عملية الاستقصاء 
وبمشاركة المطوؤرين الذين يستوعبون النتائج والتقنيات المستخدمة. يتم الحصول 
على النتائج نفسها من الاستقصاءات التمهيدية؛ مع وجود فرق في أن الموضوع 
قيد التجريب يتم مراقبته ولا يتم مشاركته. لذلك يبدو الابتكار قيد التجريب 
غريباً بالنسبة إلى عيّنات الاستقصاء. لا تؤدي الاستقصاءات التمهيدية في 
الميدان إلى التأثيرات نفسها لأن العينة يتم مراقبتها ولا يتم مشاركتهاء 
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الحدول (16-10) 
ترتيب المعاملاث في الاستقصاءات ال مختلفة 


المميزات 


الوحدات التجريبية 


ملاحظة : ۴ = مرتفع » 1 = منخفظر 


في تجربة ماء إذا تم تحفيز المطؤرين بشكل جيد وأعجبوا بالتتائج» سوف 
يتطلعون إلى فوائد الابتكار. مع الأخذ بالاعتبار قصر فترة تنفيذ الاختبار. لا 
يستوعب المطؤرون الابتكار بشكل كاف. وفقاً للفرضية السابقةء لا يستطيع هذا 


10 _ 5 بنأء الكفاءات من خلال الاستقصاء التجريبي 
10 - 5 - 1 مقدمة عامة 


تكمن آهمية ۴1 في آنه تدريب يقوم بتعزيز القيمة المعرفية لهندسة 
البرمجيات وجعله مقبولا بشكل واسع. تحديداً» تحفز ٤1‏ النمو المعرفي 
وتطوير القدرات المطلوبة في الدرايات العمليةء من أجل تأكيد النماذج 
المعروفة. إضافة إلى ذلك» تشير ۴1 إلى مواقع الضعف في المعرفة السابقة؛ 
وتحفز لإنشاء معرفة جديدة» وتركز على المشاكل التي ظهرت في عملية تحويل 
الابتكار من الحالة النظرية إلى الحالة العملية. كذلك» تقيم المنهج المتبع في 
كل عملية نقل. يلخص المؤلف في الفقرات الآتية الكفاءات التي تم الحصول 
عليها في عمليات الصيانة الاستشنائية خلال 10 أعوام من الاستقصاءات التجريبية 
لمشروع .85E۸1۸8‏ يمكن الحصول على معلومات إضافية من المرجم؟. 


لأجل التوضيح» سيتم تعريف بعض المصطلحات التي سيتم استخدامها. 
تعرّف الكفاءة على أنها القدرات والمعرفة التي تجعل من الممكن إدارة الموارد 
المتاحة من أجل الوصول إلى الأهداف التي تم تحديدها بشكل منهجي. وفقاً 
للمرجع“ يتم الحصول على المعرفة من خلال فهم المعلومات والعلاقات 
بينها وتصنيفها الصحيح. يتم تعريف القدرات على أنها تطبيق للمعرفة بشكل 
عملي تهدف إلى إيجاد الحلول لمهمة ما في بيئة حقيقية. 

يتناول مسح الاستقصاء التجريبي الحالي الصيانة الاستثنائية .)۴EM(‏ تشير 
الصيانة الاعتيادية إلى التعديلات التي تهدف إلى التغلب على السلوك الذي لا 
يتوافق مع المتطلبات» أو تهدف إلى جعل النظام كافياً ومناسباً للتطبيق 
وللابتكارات التقنية. أثبت ليمان «دصطم1* بشكل عملي أن الصيانة العادية 
تقلل من جودة النظام» وتتطلب عملية الصيانة عندئذ زمناً أكبر» وتصبح 
البرمجيات أقدم. تشير الصيانة الاستثنائية إلى التعديلات التي تهدف إلى إبطاء 
تقادم البرمجيات» وبالتالي الحفاظ على قيمتها الاقتصادية. 
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توفر المادة النظرية عمليات أكثر من العمليات التي تمت مناقشتها في 
التحليل التالي. هذا يتطلب كفاءات أكبر» على الرغم من أنها جزء من خبراتنا. 
يتم توضيح تقاصيل أخرى هنا: 

® الهندuة‏ ıÉkallة XARE) (Rverse Engineering)‏ التي تمکننامن 
المتخفض المستوى الذي يتم تزويده*. 

© إعادة التصميم»› الذي يمكتنا من الحصول على شكل جديد لبعض 
المتتجات› مع وجود جودة عالية ومستمرة في عملية تطبيق المنتجات“. 

8 يمكن إضافة عملية الاستعادة إلى القائمة السابقة وفقاً لخبراتناء وهي 
تمثل البديل لعملية إعادة البناء التي تتضمن إعادة بناء الشيفرة البرمجية الأصلية 
من الحصول على نسخة جديدة تحقق مبدأ البرمجة الهيكلية اعتماداً على 
الخصائص الهيكلية للشيفرة البرمجية. يتضمن البديل أيضاً مراغاة عملية إعادة 
الهيكلة للشيفرة البر م2:42٠‏ . 

تمت الإشارة بشكل أوسع إلى قدرات العملية السابقة في المرجع* في 
حين تدفعنا الخبرات التي تم تطويرها في المشاريع الصناعية عادة إلى الإجابة 
عن الأسفلة الآتية : 

س1: متی یجب استخدام کل عملية؟ 

س2: لماذا یجب استخدام عملية محددة؟ 

س3: ما هي التكاليف والمنافع التاجمة عن استخدام العملية؟ 

س4: ما هي المخاطر التي تتضمنهاء وكيف يمكن التقليل متها؟ 

تم إعداد حزمة معرفية استخرجت من تحليل البيانات وتعميم التتائج التي 
بصورة أكبر سوف نرمز للبنك الإيطالي الذي تطبق عليه هذه العملية”“ بالرمز 
XxX‏ (الجدول 16-0( . جمیح المعلومات التجريبية الموجودة في هذا القسم 
والقسم الذي يليه تتعلق بنظام معلومات البنك إلا إذا تم توضيح غير ذلك. 
هناك تفصيل أكبر في المرجع" '. 


يمكن إضافة الأسئلة الآتية : 
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يتضمن نوع الصيانة الاستثنائية التي آنتجت المعلومات في هذا القسم وفي 
القسم الذي يليه اختبارات سابقة تم تنفيذها على المعلومات التي تم جمعها 
خلال عملية الصيانة الاستشائية لنظام المعلومات السابق. تتطلب نتيجة الاختبار 
عمليات تحقق أكثر من خلال إعادة التجارب ممائلة. لذلك يتم الإشارة إليها 
على آنها دروس مستفادة. 

0 - 5 - 2 أعراض التقادم 

للبدء في الظروف التي تتطلب إجراء عمليات صيانة استثنائيةف من المهم 
تحديد خصائص البرمجيات التي تنكشف عند الضرورة. وفقاً لتجربة 58٤۸1۸8‏ 
في عملية الصيانة الاستشنائية أن يتم التعبير عن هذه الخصائص من خلال 
مؤشرات» وتحدد هذه المؤشرات على أنها مؤشرات تقادم. تالياًء ثمة قائمة غير 
شاملة يمكن توسحتها وفقاً لعمليات الاستقصاء التجريبية الأخرى. 

التلوث (١٠اس!آام۴):‏ العديد من مكوتات النظام» بما فيها البيانات 
والوظائف» مشمولة في البرمجية؛» على الرغم من كونها غير مفيدة لاحتياجات 
التظام. هذه الأعراض تجعل من نشاطات الصيانة أكثر صعوبة وأكثر تكلفة نتيجة 
عدم التحديد الفاعل للمكونات التي تتأئر بالتعديل. نتيجة لذلك» تكون الصيانة 
أقل موثوقية. المعايير المستخدمة في هذه المؤشرات هي : 

البرامج المكررة: البرامج التي تظهر عدة مرات بمعرفات مختلفة في 

# البرنامج في المكتبات : البرامج التي تنتمي إلى مكتبة المكوّنات للنظام. 

المعرفة المضمنة (ععلء1س0دK‏ لءللءاص۴): يتم تضمين المعرفة لمجال 
التطبيق في البرمجيات» كتأئير للصيانة السابقة. يتم دمجها بالوثائق التي لا 
يمكن تتبعها باستخدام البرمجية. لا يمكن إعادة استخدام المعرفة المضمنة من 
قبل منفذي عمايات الصيانةء وبالتالي تصبح عمليات الصيانة غير موئوقة بشكل 
أكبر لأنه لا يمكن تحديد تأثير التغييرات بشكل مؤكد. هناك العديد من المعايير 
التي یمکن من خلالها معرفة مقدار هذه المۋشرات وتعتمد على المستوى 
المعرفي للنظام. في حالتنا هذه تم استخدام الآتي : 
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8 عدد الوظائف التجارية المستخدمة: عدد الخدمات أو الوظائف التجارية 
# عدد الوظائف التي يمكن تتبعها في البرمجية: عدد الخدمات والوظائف 
التجارية» المعروفة من قبل المستخدمين› التي یمکن تتبعها من خلال 
وثائق النظام أو الشيفرة. 
# قاموس ضعيف: أسماء البيانات غير مترابطة مع المعنى الذي تحمله 
للمتغيرات والبرمجيات المرتبطة بهاء مما يؤدي إلى صعوبة في فهمها. 
هذا يتطلب جهداً أكبر فى عمليات الصيانة. 
التقارن (ع«نامuم٣):‏ يوجد الكثير من العلاقات التي تتخلل مكوتنات 
النظام آو البرمجيةء وبالتالي تصبح البيانات الناتجة والقدرة على التحكم أكثر 
صعوبة للفهم والإدارة. يزود الإطار النظري عدة معايير لعمليات التقارن. تالياء 
تم استخدام علد محدد من عمليات التقارن الداخلي لبرنامج ما بين إجراءات 
البرمجيات» تم استخدام المعايير الآتية : 
أنه مالك البرنامج ۴ إذا كان يحتوي الوظائف اللازمة لتعدیل محتویات ۴1 . 
# الملفات الباثولوجيكية: یسمی ۴۱ ملفا باثو لر جيكياً (a1ءنعه1هطاه۴)‏ إذا 
كان هناك برنامجان أو أكثر في النظام 8 قادرة على إجراء تغييرات على ۴ . 
إذا كان هناك برنامجان يمتلكان الملف نفسه» يتم تقارنهما بشكل صارم لأن 
كليهما يعرف بنية الملف ومحتوياته. يؤثر كل تعديل في الهيكلية أو في المحتويات 
في جميع البرامج التي تمتلكهاء وقد يختلف التأثير من برنامج إلى آخر. 
عندما يحتوي النظام على تقارن مثل هذه يکو له تأثير في کل تعدیل یتم 
إجراؤه على الملفات الباثولوجيكية. بالإضافة إلى ذلك» بما إن محتويات 
الملف الباثولوجيكي مرتبطة بسلوك عدة برامج» يجب وضع اختبار يكون قادراً 
على فحص سلوك برنامج واحد آو عدة برامج فقط. في الحقيقةء يوئر كل 
سجل للملف الباثولوجيكي في البرامج الباثولوجيكية بشكل مختلف. 
الهيكلية الضعيفة (Poor Architecture)‏ : في العادة یتم تلفيذ عمليات 
الصيانة التي تتم خلال فترة عمل النظام وفقاً لمناهج بنائية مختلفةء وفي بعض 
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الأحيان تتعارض مع بعضها البعض. يؤدي ذلك إلى اتخاذ قرارات غير مناسبة 
خلال عمليات الصيانة تؤدي إلى إضعاف هيكلية النظام» وبالتالي زيادة الجهد 
اللازم للصيانة. المعايير المستخدمة للإشارة إلى هذه العواقب التي تنتج من 
القرارات وتحك من مقدار المؤشر هي : 
ملفات غير مستخدمة: الملفات التي تم إنشاؤها وتحديثها وإلغاڙؤها من 
دون قراءتها. 
# الملفات المتقادمة: الملفات التي لم يسبق تحديثها وحذفها. 
# الملفات المؤقتة: الملفات التي تم انشاؤها وقراءتهاء ولكن لم يسبق 
تحدیثها وحذفها. 
البيانات ذات الدلالات المكررة: البياتات التى تكون المجالات المحددة 
لها مماثلة المجالات المحددة لبيانات أخرى أو تكون محتواة فيها. 
# البيانات المكررة حسابياً: البيانات التى يمكن حسابها بدا من بيانات 
أخرى فى قاعدة البيانات نفسها. 
0 - 5 - 3 الهندسة العكسية 
عندما تبدآ عملية الصيانة الاستشنائية» كان العمر المتوسط للبرنامج 12 عاماً 
تقويمياًء لكن أساسها قد كتب قبل ذلك ب 23 عاماً. لمنع إهدار الجهد أو 
عمليات المعالجة التى تم تطبيقها على النظام كان الفحص بهدف تحديد 
والقضاء على أسباب التلوث. النتائج موضحة في الجدول 17-10, 


الحدول (17-10) 
قیم مقیاس التلوث التي تم قياسها قبل وبعد المعالحة في الهندسة العكسية 
مقدار التلوث قبل الفحص بعد القفحصس 


من الواضح كيف أن القضاء على التلوث» على الرغم من كونه يدوياًء قد 
قل من موجودات البرمجيات الفعلية التي يجب التعامل معها عن طريق الصيانة 
الاستشنائية » فهي توفر في إجراءات عملية الصيانة الاستفنائية. يمكن أن ينتج 
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التلوث نتيجة عمليات الصيانة الاعتيادية. لذلك. أول الدروس المستفادة هي : 

فحص البرمجية بهدف تجريدها من موجوداتها السابقة والناتجة من تطبيق 

إذا تم إجراء هذا الفحص على أسس اعتيادية» فإنها تحتاج إلى جهد آقل› 
ویمکن استخدامها لمراقبة النظام البرمجي وتفادي وچود مکوّنات غير مفيدة. 

تم تنفيذ أولى الخطوات لتحديد المعرفة المضمنة من خلال مسح طق على 
منهم وصف وظائف الأعمال التي كانوا يعلمون عنها في النظام البرمجي الذي 
استخدموه أو قاموا بصیانته : 

# عدد وظائف الأعمال المستخدمة: 935, 

تم اعتماد عملية الفحص لتحليل عدد الوظائف القابلة للتفسير في الوثائق 
والشيفرة البرمجية للتظام البرمجي. 

عدد الوظائف التي یمکن تتبعها في البرمجية: 25. 

كان من غير الممكن تحديد البرامج التي توفر وظائف النظام اأ 910 الأخرى. 

الدرس الذي تم تعلمه هو: 

# الحصول على المعرفة من البرامج يكون مكلفاً وذا موثوقية منخفضة. 
من الضروري تحديث الوثائق للحفاظ على قابلية تتبع البرنامج. لذلك» من 
الضروري إجراء فحص مستمر للقابلية على التت . 

يظهر الاستدلال المتقق عليه بشكل عام بأن عملية الهندسة العكسية تهدف 
لذلك» تم تنفيذ الهندسة العكسية. 

استخدمت العملية النتين من وظائف الأعمال لتنفيذ مهمتين حرجتين : 
الأولى من أجل إجراء الهندسة العكسية للبرامج» والثانية من أجل إجراء 
الهتدسة العكسية لقاعدة البيانات. عادة ما تعتمد الوظائف التي تم اختيارها في 
بيئات مختلفة وحديثة وذات سمعة جيدة في المجتمعين التجاري والأكاديمي. 
إضافة إلى ذلك» كانتا ذواتي تكلفة عالية عند شرائهما وعند استخدامهما. لسوء 
الحظ أصبحتا غير ملائمتين : تم إيقاف الوظيفة الأولى عندما تخطى عدد نقاط 
القرار في البرنامج الحد المعطى» هذا الحد كان أقل من عدد نقاط القرار في 
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الشكا (9-10): 
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بين العلاقات بين الوحدات تم انشاؤه للبرنامج ۸0000 
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وكافية للنظام). 


البرمجي» لأنها تهدف إلى تتبم إجراءات المستخدمين وتعطلب خدمات مناسبة 


المعلوماث المراد تحليلها أيضاً في هذه الحالة. 
0 كمثال» العلاقة البيانية بين وحداث البرنامج (الأكثر أآهمية في النظام 


تخطت المعلومات المراد تحليلها الحد المعطى. كان الحد المعطى أقل من 


التطبيق. الأداة الثانية كان لها سرعة استجابة كبيرة (يحدود 5 أيام!) عندما 
_ تضمن العديد هن اليرامج وحداثت تم 


آنها أعلى من الحد الموصى به من قبل مهندسي اليرمجياث. 


لم تصل معالجة عملية الهندسة العكسية إلى هدفها وهو تأكيد فهم البرمجية. 
في الحقيقة» لم تساعد الوثائق التي تم الحصول عليها في فهم البيانات والبرتامج» 
والسبب الأساسي لذلك هو أن الجودة الثقنية الخفضت بشكل كبير. التفاصيل 
وعمليات الفحص تتوافر في المرجع“» هذا ملخص لبعض النواحي المهمة: 

# 75 في المثة من البرامج لها قيم محددة ما بين 75 - 185 (تقريياً)» أي 


تقارنها بشكل صارم. يبن الشكل 


الدروس المستمادة ھی : 


عملية الهندسة العكسية فاعلة فى الحصول على وصف ذي مستوى 
مرتفع »› بدا من مستوی تجريدي منخفض› لكن مستوى جودة الوثائق يرتبط 
بشكل كبير بمستوى جودة المكونات التي تمت معالجتها. لذا فإن عملية 
الهندسة العكسية تكون غير قادرة على تحسين عملية الفهم» بدلا من ذلكء 
يكون الهدف من عملية الهندسة العكسية هو الحفاظ على قابلية التتبع بين 
على سبيل المثالء عندما تقوم عملية الصيانة بتغيير الشيفرة البرمجية لتصبح 
هيكليتها جيدة ولا يتتج منها أي ضعف كبير» يمكن بعد ذلك استخدام عملية 
الهندسة العكسية لإعادة بناء هيكلية البرنامج بعد انجاز عملية الصيانة. من المهم 
مراقبة مستوى فهم الوثائق؛ نتيجة لضعف في الشيفرة البرمجيةء وبالتالي 
مستوى فهم الوثائق الذي ينتج من عمليات الصيانة 22.2 , 


© تتضمن عملية الهندسة العكسية عدة نشاطات» التي يمكن وصفها بشكل 
رسمي»› وبالتالي دعمها عن طريق الأدوات الأوتوماتيكيةء ما يژدي إلى 
انخفاض تكاليف العمليات. 

يوجد خطورة في عملية اختيار الأدوات لأنها قد تكون غير مناسبة 
للنظام» ويچب أيضاً وضع هله الخطورة بالاعتبار حتی عندما پکون لهذه 
الأدرات سمعة جيدة في السوق» ولم يتم اختبار فعاليتها من خلال اختبار 
الإجهاد على عينة مناسبة من البرامج الحقيقية. 

0 - 5 - 4 الاسثعادة 

من الحلول الممكنة للتغلب على المعرفة المضمنة إعادة هيكلة التظام 
السابق قبل تطبيق الهندسة العكسية. هذه العملية بسيطة» وهتاك عدة أدوات 
يمكن أن تقوم بها. ولكن لسوء الحظ هذه الأدوات لا تساعد في حل مشكلة 
الفهم لأنها تزيل مشاكل التحكم في البرنامج» لكنها لا تقوم بتغيير العدد الكلي 
لنقاط القرار. لذلك» لا تتغير القيمة المحددة» وتبقى الأوضاع المشابهة للشكل 
0 بلا تخيير. تقوم الأدوات بتغيير موقع أو تكرر جزء من الشيفرة البرمجية 
بهدف القضاء على المشاكل» وفي العادة يكون الموقع النسبي لأجزاء الشيفرة 
البرمجية مناسباً ويعبّر عن معنى ما لذلك يكون تغيير موقع أو تكرار شيفرة ما 
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من دون مراعاة المعتى قد يۇدي إلى التقليل من مستوی فهم البرنامج. 

لهذه الأسباب» تم تعريف شكل جديد من عملية الصيانة الاستثنائية وتم 
تطبيقها على نظام البنوك: الاستعادة. بالتفصيل» تعمل الاستعادة على 
إعادة بناء البرمجية وفقا للمعنى الذي تحمله الشيفرة البرمجية. من أجل فهم 
أفضل للشيفرة البرمجية» تقوم بما يأتي : 

# تزيل البيانات منتهية الصلاحيةء آي البيانات الموجودة ولكن لم يسبق 
آن تستخدم. 
الميتةء وبالتالي ينتج منها نتائج غير قابلة للاستخدام. 

8 تزيل الأوامر متتهية الصلاحيةء أي الأوامر التي لم يسبق استخدامها. 

#8 تحسن من قيمة البيانات والأسماء الإجرائية» وفقاً لتلك التى تكون غير 
مفيدة. 

بعد التعرض للظروف السابقة» يجب أن يتم إعادة بناء الشيفرة البرمجية 
وفق الخطوات الآتية : 

إزالة عمليات الشرط 1۴ الإجرائية» لأن 1۴ تحتل وحدتين من الشيفرة» 
للقضاء على عملية 1۴ء يجب استدعاء كل وحدة فى سياق مختلف»› بناءَ على 
حالة البرتامج. 


الحدول (10 - 18) 
مقایسات تظهر تأثیر الإصلاح (Restoration)‏ 


الإجراءات قبل الإصلاح بعد الإصلاح 
بيانات منتهية (564) 3.597 0 


0 1.252 
639 1.891 


1.232.27 1.502.734 
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يلص الجدول 18-10 نتائج عملية الاستعادة. يظهر الشكل 10-10 تبحسن 
الرسم البياني المتعلق ب ۸0000 بعك إجراء الاستعادة بعد تحسين هيكلية 
البرمجيةء كان من الممكن إعادة ثسمية 63 فى المئة من البيانات والإجراءات»› 
وإيجاد فهم أفضل لمجالاتهم. بناءً على ذلك» أصبح من الممكن تحسين الضعف 
الحقيقة» ازداد عدد الوظائف التى يمكن تتبعها فى البرمجية إلى 852. 

لإتمام العمل» أتاح تحسين عدد القيم المحددة للبرامج (لثسبة من البرامج 
مقداره 75 فى المثة أصبح عددها بين 5 و15)» لكتها لا زالت فرق الحد 
الموصى به من قبل هندسة البرمجيات. 

بعد إجراء الاستعادة» لا تزال البرامج تحتوي على نوع آخر من التقارن: 
سبيل المثال» تشير إلى أن سبعة ملفات تعاني الباثولوجيكية فى 40 برنامجاً. 
بقيت هذه التقارنات من دون تغيير حتى بعد إجراء الاسترجاع : 

الدروس المستفادة هي : 

8 تحسن عملية الاستعادة المعرفة المضمتة والضعف فی القاموس والتقارن 
الجزئي. تبقى جودة الهيكلية والتصميم من دون تغيير. فمثلاً لا تقوم 
بتحسين المعلومات المخبآة في وحدات النظام. 

تم تحسين الجهد والكفاءة لعملية الصيانة. 

یتطلب الاسترجاع تقنيات دقيقة ولكن ليست رسمية» وبالتالى لا يمكن 
دعمها عن طريق الأدوات» لذئك تحتاج هذه العملية إلى جهد 
شخصي» وبالتالي تكون مكلفة. 

# الخطورة الأخرى نتيجة المهارات المحددة التى يجب أن يمتلكها 

المطرّرون وتتطلبها العمليات 

# لا يمكن وضع تعريف رسمي لإنهاء العمليات» فهو يمثل تطبيقاً 
مستمراً یحدد التتحسن المستمر فی الشيفرة أو فی قاعدة البياتات»› لکن 
هذا يعمل على زيادة خطورة رفع التكاليف. 

يمكن التقليل من خطورة ارتفاع التكاليف عن طريق تقسيم العمل إلى 
شرائح مناسبة لكل مكرّن سيتم استرجاعه, تتوقف العملية بعد نهاية كل 
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شريحة عمل» كلما كانت الشريحة تتطلب عملا أكبر كانت جودة النظام 
المُستعاد أفضل. لذلك يجب أن يحدد مدير المشروع شرائح كبيرة من 
العمل للبرامج ذات الأهمية لكي 


# يمكن التقليل من خطورة مهارات المطورين عن طريق تدريبهم تدريباً كافياً. 
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الشكل (10- 10): رسم بياني يبين وحلة العلاقات المكؤنة للبرنامج 40000 بعد 
عملية الاسترجاع 


0 31 22 1921 1011 8 7 6 5 4 3 2 
عدد برامج المالك 
الشكل (10- 11): توزيع الملفات الباثولوجيكية 
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يتوجب الآن إجراء اختبارات على النظام البرمجي الذي تمّت صيانته على 
سس اعتيادية» بقياس آعراض التقادم. عندما تتعدى هله الأعراض حدوداً 
معيّنة» يجب إجراء عملية الاستعادة. يسمح ذلك بتجديد النظام عن طريق 
عمليات استعادة بسيطة» بتكلفة وخطورة منخفضتين 


0 - 5 - 5 إعادة التصميم 

من الأهمية بمكان إعادة التصميم للك للقضاء على أعراض التقادم التي لم 
تستطیع عملية الاستعادة إزالتها. آدى تطبيقها تطبيقها إلى التتائج المبيّنة في الجدول 
0. أظهرت القياسات التحليلية كيف أن إعادة التصميم مكننا من التغخلب 
على جميع أعراض تقادم التظام البرمجي. 

تعتبر هذه العملية معيقة للعمل لأنها تتطلب معالجة جميع البيانات 
والإجراءات في نفس الوقت لجميع أجزاء النظام. لذا من الضروري إيقاف 
النظام البرمجي عن العمل خلال عملية إعادة التصميمء إضافة إلى ذلك 
يجب إيقاف جميع إجراءات الصيانة الاعتيادية إلى أن تنتهي هذه العملية. من 
المستحيل تطبيق عمليات إعادة التصميم على البرمجية التي تستخدمها 
الشركة. 


الحدول (10 - 19) 
القياسات قبل وبعد إجراء عملية إعادة التصميم 


حدّد المؤلف عملية إعادة التصميم التكرارية““ للتغلب على هذه 
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المشكلة. تسمح هذه الطريقة بتجزيء النظام إلى مكوّنات» ويتم إغادة التصميم 
لكل منها بشكل مستقل عن الأخريات. يتم ضمان التوافق بين المكزنات القديمة 
والمكرنات التي تجري عليها عملية إعادة التصميم خلال تنفيذ هذه العمليةء 
بذلك يمكن الاستمرار في استخدام النظام بشكل كلي والدخول إلى البيانات 
والوظائف القديمة التي تجري عليها عملية إعادة التصميم. الوقت الذي يستمر 
فيه النظام بالتوقف عن العمل يكوك قلیلا ويعتمد ذلك على حجم المكون 
الذي يتم إعادة هيكلته. 


ثم تنفيذ هذه العملية على نظام صناعي يدعم منتجين للمواد الكيميائية 

في البداية آظهرت العملية قابلية نقل إعادة التصميم» حتى بعد التدخل 
لإجراء التكرارات. خلال فترة إعادة التصميم» التي استغرقت 18 شهراً احتاجت 
إلى ثمانية وتسعين تدخلاً لإجراء المعالجة عليهاء تم إيقاف 63 منها عن العمل 

ة ثقل عن 10 آيام عمل» 28 لمدة تتراوح بين 11و15 يوماًء في حين أوقف 
7 منها لمدة تتراوح بين 18 و28 يوماً. 


الدروس المستفادة من هله التجربة ھی : 


8 هدف العملية هو تحسين الجودة التقنية للبناء الهندسي والتصميم› 
بالإضافة إلى تحدیث القدرات الوظيفية والتقنية › عملية إعادة التصميم 


فاعلة في إزالة أعراض التقادم» التي لا يتم إزالتها عن ن طریق عملیات 
الصيانة الاستثنائية أخرى. 

۵ يمكن إجراء عمليات إعادة التصميم المكررة من دون الحاجة إلى 
استرجاع النظام. 

۵ تمکننا عملية إعادة التصميم من تحديث العمليات التي پزودها البرنامج› 
وإبطاء التناقص في القيمة التجارية. 

الخطورة الرئيسة في هذه العملية في تحديد المكونات الواجد 

إعادة هیکلتها في کل فترة برمجية تكرارية : التقسيم غير المناسب قد 
يؤدي إلى زيادة فترات إعادة التصميم وبالتالي فترات أطول من الوقوف 
عن العمل خلال فترات الصيانة. 

© يمكن التقليل من المخاطرة عن طريق استخدام تقنيات مناسبة* ,. 
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5-0 - 6 الملخص 


يمكن تلخيص الأمر بتوضيح أن النتائج التي نحصل عليها خلال تنفيذ 
عمليات الصيانة الاستثنائية والدروس المستفادة من الاختبارات التجريبية» تم 
توضيحها في الفقرات السابقة هي الان ملخصة. سيتم عرض الملخص على 
شكل آجوبة للأسثلة التي تم سردها سابقاًء التي تعبّر عن مدى فاعلية عملية 
صيانة الصيانة الاستشائية. تم تنظيم التعليقات في الجدول 20-10 . 


الحدول (10- 20) 
توليفة ختويات الاختصاص 


عمليات الصبائة الاستائية البرمجية 


منی تستخدم کل بعد تتفي مجموعة من انشطة 
الصيانة التي تعدل الشيفرة 
البرجية. عندما يكون إدخال 
المعرفة المضمنة في البرمجية من 
خلال الصيانة بطيتاً. عند تقادم 
النظام البرجي» جب أن يتم 
التحقق لشوصيف الإرث 


ية | جب أن تستخدم مراقبة تأثير 
التلوث الذي تحدده الصيانة. إذا 
تغذ ذلك في اللحظة الملائمة» 


المعرفة الضمئة كبيرة أ 2 


والوحدات متقارنة. عند 
تقادم النظام البرجي› 
يجب أن يتم العحقق 


لتوصيف موجودات | يت 


البرتجية قبل تطبيق هذه 
العملية 


تسين الشمولية وتركيب تة 


تکون الصيانة العادية 
مجدية أكثر من حيث 


ين العكلفةوالسرعة 


تافين | والموئوقية. 


الأنشطة مؤغتة تقريباً؛ المنفعة 
النحققة هي عملية التتبع التي 
تيح للأفراد الذيسن بجرون 
الصيانة إجراء التغيرات بسرعة 


تكاليف هله العملية 
مرتفعة جدا؛ أما المنافع 
فتشمل تحسين القدرة على 
الصيانة التي تفلل من 
تكاليف الصيانة. 
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القدرات الوظيفية 
والتقنية. 


تحسن القدرة على الصيانة 
وتحافظ على الاستثمارات 
في إنتاج البرمجيات لأنها 
دمن عمر النظام. 


دلیلاً تجریبیاً آو أن پستنبط مدی 
صلاحيتها باستخدام التحقق 
من سلوك الأداة التي يتم إجراء 
ا-ختبار ال جهاد عليها. 


0 - 6 الاستتتاجات 


هدف هذا الفصل إلى تقديم المبادئ الأساسية المتوفرة في المادة النظرية 
للعديد من المؤلفين والباحثين» وللطلاب والباحثين المهتمين في الأبحاث 
التجريبية. يمثل هذا الفصل مقدمة إلى الاستقصاء التجريبي كطريقة للربط ما بين 
هندسة البرمجيات والعلم. يجمع الكثير من الخبرات المنشورة في مشروع 
۴۴۵8. لذلك تم توجيهه إلى القرّاء الذي ينوون أن يجعلرا الاستقصاء 
التجريبي جزءاً من عملهم. يمكن للقرّاء المهتمين أن يبدأوا باستعراض المراجع 
المقترحة والانطلاق منها إلى مراجع أكثر. 
يشير هذا الفصل بأآن عمليات الاستقصاء التجريبي في هندسة البرمجيات 
لها خصائص مشابهة لخصائص العلوم الإنسانية أكثر شبهاً بالعلوم الطبيعية› 
نتيجة لطبيعة العملية التي يوجهها الإنسان. هذه الطبيعة تتطلب ما يأتي : 
# آخذ الاحتياطات خلال عمليتي التصميم والتنقيذ لعملية الاستقصاء 
النجريبي لتجنب تحديد تآثيرات غير موجودة. 
# التكرارات من أجل تأكيد العلاقات المعقدة التي تنتج من الخصائص 
الإنسانية خلال انشاء البرمجية 


المخاطرة التي تحيق بهذه 
ن | العملية هي شرط الإنباء : 
وبغياب هذه المخاطرة قد 
تحدد فترات تنفيذ طويلة 
وجهدأكيراً. وهذاقد 
يتلف توازن النكلفة- 
المنفعة. تثكون إجراءاث 


الجيد الذي يجب إنفاقه 
ومستوى جودة البرجبة 
الذي يجب الوصول إليه؛ 
عند الوصول إلى أي من 
نقطتي البداية هاتين؛ 
تتوقف عملية الأستعادة. 
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برمجية تكراربة» تتكون 
إجراءات التخفيف من 
الملخاطرةالاستخدام 
الصحيح للعملية 


الموصوفةفي المرجع 


ة|44. 


# تقنيات وقدرات من أجل إعادة دقيقة للتجربة أو التخطيط لتخيير أحد 
العوامل أو أكثرء من أجل تحديد عائلة البرامج وتعميم النتائج. 
بالإضافة إلى ذلك يقوم هذا الفصل بتحليل حصيلة 10 أعوام من 
الخبرات في الأبحاث التي تم إجراؤها في مشروع 55۸1۸8 من أجل دعم 
وتحسين عملية نقل نتائج البحث والتقنيات المبتكرة في العمليات الصناعية. 
تفرض طريقة جمع البيانات خلال عمليات الإعادة التي تكون ضرورية للموازنة 
ما بين التكلفة والفوائد وتحده المخاطر وتبيّن آلية إضفاء الطابع المۋسسي على 
الابتكار» على الرغم من أن ذلك ليس ضرورياً لتأكيد النظريات الأساسية. كما 
أشار هذا الفصل إلى أن كل نوع من آنواع عمليات الاختبار يساهم بطريقة 
مختلفة في تفضيل طلب ابتكار ما. 
تبرز هذه الخبرة كيف أن عملية الاستقصاء التجريبى فى هندسة 
البرمجيات» كما في العلوم الأخرى عامل فاعل في زيادة الكفاءات في أي من 
مجال من مجالات المعرفة. أخيراًء في هذا الفصل بقيت هذه الأمور من دون 
وجود حل لها: 
8 دراسة الطرق والأدوات للمبادىء المنهجية التي تجعل نتائج الاختبار 
دقيقة وذات مولوقية. 
# تطوير أساليب العمل من أجل حفظ التجارب بحيث يمكن إعادتها بدقة 
أو بتغيير عوامل التجربة. 
استخراج البيانات الموصى بها وجمعها خلال عمليات الإإعادةق التي 
تكون ضرورية ومناسبة لجعل الابتكار قيد الدراسة مقبولاً من قبل 
المشاركين. 
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11 
أساسيات المنهجات السريعحة 


(Alberto Si1litti} البرتو سيف‎ 
(Giancarlo Sussi) وجانکارلو سوتشي‎ 


1 - 1 مقدمة 


المنهجيات السريعة هي مجموعة من تقنيات التطوير المصممة لعَنوْنة بعض 
مشكلات تطوير البرمجيات الحديثة (أي المشاريع التي تعجاوز الموازنة أو 
تتجاوز جدول التنفيذ). لا يبدو أن مثل هذه المنهجيات مفيدة لأي نوع من 
مشاريع البرمجيات أو أن تكون حلا للحد من تكاليف المنتج وزيادة جودثه. 
لكن»ء في سياقات محددة ولمشكلات محددة» تساعد المنهجيات السريعة 
المطررين في التركيز على أهداف العملاء وتسليمهم المنتج الصحيح من دون 
هدر الوقت والجهد في أنشطة ليست ذات قيمة للعميل. 

تتطلب منهجيات تطوير البرمجيات التقليدية (آأي منهجية الشلال 
)Waterf1)‏ والحلزونية (لهiصم8)‏ والتكرارية (عااةإء)1) وغيرها) معرفة عميقة 
في مجال التطبيق وفي احتياجات العميل الفعلية (بما في ذلك المستخدم 
النهائي للتطبيق). لكن؛ء هذه المعرفة نادراً ما تكون متوافرة حتى في الحالات 
التى يطلب فيها العميل إجراء تغيير في أثناء مرحلة التطوير. لسوء الحظ› 
تمي عملية تطوير البرمجيات بعدم اليقين (را«نه٤e۲ءصتا)‏ وعدم القدرة على 
التراجع (رانااوعء۷ه۲م) *؛ لذا لن يكون تخطيط كل شيء مسبقاً مفيداً في 
العديد من مجالات التطبيقات. 


عدم اليقين (راهنه)۲٠٠«0ا)‏ يعني أن المتطلبات غير ثابتة والعميل غير قادر 
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على تحديدها بطريقة كاملة ومتماسكة. غالباً ما لا يكون العملاء قادرين على 
تحديد الوظائف الرئيسة المطلوبة ويغيّرون رأيهم بصورة متكررة. 


عدم القدرة على التراجع (واالاطاإم۷ء٣1۴)‏ تعني أنه حتى لو كانت البرمجية 
معنوية» فإنه لا يمكن تغيير بعض القرارات من دون التأثير بعمق في جدول 
تنفيذ المنتج والموازنة. هذا الأمر مفهوم في علوم أخرى كالهندسة المدنية. إذ 
يكون العميل مدركاً أنه لا يمكنه طلب تغيير شكل البناء في مرحلة إضافة 
السقف. لكن في مجال البرمجيات» غالباً ما لا يدرك العملاء أن إجراء 
تعديلات معينة له تأثير قابل للمقارنة. 

آما العواقب الرئيسة لعدم اليقين وعدم القدرة على التراجع فهي : 

1. المعرفة التامة اللازمة لبناء نظام لا تكون متوافرة دائماً و/ أو تكون 

2. وضع افتراضات بتجريب بعض الحلول» ومن ثم إلقائها جانباً إذا لم 

تكن مطابقة؛ وهذا لا يُطبّق دائماً (هدر للوقت والمال). 

القدرة على التراجم من خلال وضع طط مفصلة. فهم یحاولون تحدید کل 
شيء في البداية وذلك لتجنب التغيرات المكلفة التي قد تطلب في مراحل 
متقدمة من المشروع. لكن في مجالات تطبيقات معيَّنة ولبعض المشكلات 
المحددةء لا تعمل الخطط ببساطة آو قد لا تكون ذات فعالية. وهذا صحيح 
بض النظر عن كفاءة العاملين في المشروع. 

حتى لو كان يفترض أن تساعد الخطط الشركات» يعترف العديد من مدراء 
المشاريع آنه في أنواع كثيرة من المشاريع لا يمكنهم متابعة المشروع بسبب 
احتياجات السوق» وغالباً ما ينجحون. 

تقر المتهجيات السريعة بصعوبة تعريف خطط تفصيلية عند بدء مشروع 
ويتضمن دعم التغييرات التي تطرأ على عملية التطوير. بهذه الطريقة» يتم جمع 
المتطلبات ومناقشتها مع العميل لكامل فترة المشروع بحسب الانطباعات والآراء 
التي يزود العميل بها فريق التطوير. تتم عملية التطوير بطريقة الفترات البرمجية 
الٹٹتکګکرارية (Iteratively)‏ ومن ثم يتم تسليم المنتج للعميل بعد كل فترة تكرارية 


لتقييمه (وتستغرق الفترة من أسبوعين إلى شهرين في منهجية ۴×). 
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ترز المنهجيات السريعة على الناتج النهائي لعملية التطوير (آي الشيفرة 
البرمجية) وعلى القيمة التي توفرها للعميل. المعطيات الإضافية (آي وثائق 
التصميم والتوثيق الكثير› إلخ) تعتبر هدراً لأن إنجازها يتطلب وقتاً وتصبح غير 
مفيدة ومضللة إذا لم تنجز بالطريقة الملائمة. إن الصيانة الضعيفة للتوثيق هو أمر 
شائع في حال حدوث تأخير في التطوير. في مثل هذه الحالات» يبذل كل الجهد 
في البرمجة واختبار الشيفرة البرمجية من دون تحديث التوليق بصورة ملائمة. 


بما إن هذا السيتاريو مشترك تماماء فإن الفكرة الأساسية هى التقليل من 
الزمن المستغرق لإنجاز التوليق غير الضروري واستخدام الأدوات المؤتمتة 
لإعادة التصميم لإنتاج المنتج عند الحاجة, 

غالباً ما يُساء تفسير المنهجيات السريعة. على سبيل المثال» يقول البعض 
إنهم يطبقون المنهجيات السريعة بسبب ما يأتي : 


1. أنهم يتنقلون فوراً إلى البرمجة من دوت كتابة وثائق التحليل والتصميم. 
2. أنهم لا يقومون بكتابة التوثيق. 
3. أنهم يقللون من الوقت المستغرق في الاجتماعات. 


لكن»ء هله ليست منهجية سريعة» بل برمجة بطريقة  eowboy coding‏ , 
توفر المنهجيات السريعة طريقة لتنظيم تطوير البرمجيات من نواح تتجاوز 
الخطط. لكن لا يزال ذلك ضمن عملية صارمة يجب اتباعها. غالباًء يشكل 
استخدام المنهجيات السريعة تحدياً أكبر من تطبيق أساليب تطوير البرمجيات 
التقليدية بما إن المنهجيات السريعة تتطلب مستوى أعلى من الالتزام ومهارات 
أكبر وغير ذلك. إن تطبيتق وإدارة هذه المنهجيات أمر في غاية الصعوبة لكنها 
مصممة للتغلب على التحديات التى يفرضها سرف البرمجيات الحديثة (أي 
توفير هذه البرمجيات في السوق خلال فترة قصيرة ومتطلبات الجودة العالية 
وغير ذلك). 


(8) البرجة بطريقة رهط ٠٠#‏ هي مصطلح بستخدم لوصف تطوير البرجيات» يكون للمبرجين سيطرة 
على عملية التطويرء بما في ذلك التحكم بجدول المشروع ولغة البرجة والخوارزميات والأدوات وآطر العمل 
وأسلوب البرجة. قد تشم البرمجة هنا من قبل مبرمج واحد أو مجموعة من المبرجين. تستخدم هذه الطريقة عندما 
يكون هناك مشاركة قليلة من المعنيين بالأعمال أو عند وجود إدارة تحكم الجوانب غير التعلقة بعطوير المشروع 
فقط› کالأهداف العريضة والجداول الزمئية ونطاق العمل (الترجم). 
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إضافة إلى ذلك تعطلب المتهجيات السريعة سرعة أكبر مما يتطابه الهيكل 
التنظيمي لشركة (أي أنواعاً جديدة من العقود وقرارات أكشر يترك أمرها لفريق 
العمل. . . إلخ) وأشخاصاً أكثر مرونة وذوي مهارات عديدة والقدرة على أداء 
العديد من الأدوار ضمن فريق التطوير. وبتاء على ذلك لا تكون المنهجيات 
السريعة ملائمة للجميع وهي لا تلائم جميع المشاريع البرمجية. 

يحلل هذا الفصل المفاهيم الأساسية للتطوير السريع والصعوبات التي 
تعترض التنفيذ الفعال. حتى لو كان هناك العديد من منهجيات التطوير السريعة 
(البرمجة القصرى ۲× صسء؟» أسلوب تطوير التظم الديناميكية («[082)» 
لهاورع٥.‏ النمذجة السريعة وغيرها)ء فإنتا نركز على الاصدار الأول من البرمجة 
القصوى ۴× وذلك لأنها الأكثر شهرة. 


1 - 2 المنهجيات السريعة 

المنهجيات السريعة هي عائلة من تقنيات التطوير المصممة لتوفير المنتج 
ضمن الوقت والموازنة المحددين بحيث يكون ذا جودة عالية ويحوز على رضا 
العميل” ” . تتضمن هذه العائلة العديد من الأساليب المختلفة» وأشهرها : 

4, 2 (extreme Programming (XP البرمجة القصوى‎ © 


“195 Scrum ® 


# أسلوب تطوير النظم الديناميكية ٠9()5850(‏ 

© تطوير البرمجيات التكبفية (۸82) 

6 العائلة الکريستال © 

إن هذدف هله الأساليب هو تسلیم المنتجات بشکل سرع وبچودة عالية» 
على تطویر البرمجيات 7 . 

طورت مبادئ الإنتاج باتباع منهجية ‏ 4ء1 في أثناء عقد الخمسينيات 
من القرن الماضى من قبل شركة تويوتا" . تتضمن هذه المبادئ العديد 
من الممارسات التي تعتبر اليوم جزءً من معظم العمليات التصنيعية كعمليات 
«فى الوقت المحدد عصنا-«ذاوسز» وإدارة الجودة الشاملة وتحسين العمليات 
المستمر. 
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آما المبدآ الأساسي في الإنتاج باتباع منهجية صهه] فهو تحديد الهدر 
وإزالته (aفسص‏ باللغة اليابانية) - آي أن الهدر هو آي شيء لا يضيف قيمة 
للعميل في المنتج النهائي. 

بما إن المنهجيات السريعة هي تطبيق لمنهجية ة1 في حقل صناعة 
البرمجيات» فإنها تركز على ما يأآتي : 

1. توفير قيمة للعميل. 

2. إرضاء العميل. 

إن توفير قيمة للعميل يتضمن أن يعمل فريق التطوير على إنتاج ما يوفر 
قيمة والحد من الأمور الأخرى إلى الحد الأدنى. تشدد المنهجيات السريعة على 
إنتاج ميزات مفيدة فقط (من وجهة نظر العميل) وتسليمها للعميل. إن إنتاج آي 
شيءَ آخر غیر متطلب یعتبر خطاً. 

تحديدآً إن إضافة ميزة غير مطلوبة لا تتطلب جهداً فحسب» بل إنها 
تضيف شيفرة برمجية إضافية؛ التي قد تتضمن أخطاء وتجعل الشيفرة البرمجية 
أكبر وأكثر تعقيداً ما يصعب من صيانتها وتصحيحيها وتحسينها. 

للحد من الهدرء تدعي المنهجيات السريعة”" أنها : 

© تكيّفية بدلاً من أن تكون توفعية. 

© أنها قائمة على الأشخاص بدلا من كونها قائمة على العمليات. 

لضمان رضا العملاءء یتطلب الأمر وچود تعاون وٹیق بين فریق التطوير 
والعميل. لذا: 

© تکون المتطلبات محلدة بالكامل ومفهومة بالشکل الصحيح. 

8 تعكس المنتجات النهائية ما يرغب به العميل تحديد لا أكثر ولا أقل. 
1 - 3 بيان منهجية التطوير السريع 

يلخص بيان متهجية التطوير السر یع (http://www .agilemanifesto.org/)‏ 
الخلفية الأساسية والمشتركة لجميع المنهجيات السريعة. تعرّف هذه الوثيقة 
هدف المنهجيات السريعة وهي النقطة المرجعية لمجتمع البرمجة كاملا 

تركز المنهجيات السريعة على العامل البشري في عملية التطوير وأهمية 


371 


التواصل المباشر وجهاً لوجه بين المشاركين والمساهمين في المشروع» وقيمة 
البساطة المتصورة کالحد من الهدر ونحسین مستمر في العمليةء کہا هو التحول 
فى صناعة البرمجيات لإدارة الجودة الشاملة" . 


القيم لار ا الآتية : 

1. الأفراد وتفاعلهم يفوقون أهمية العمليات والأدوات: يركز بيان 
المنهجيات السريعة 4۷ على التعاون بين المطورين والدور الإنساني في العملية 
وفي المؤسسة خلافاً لعمليات وأدوات التطوير المؤسسي” . 


2. تعاون العميل يفوق أهمية العقود: يعطي بيان المنهجيات السريعة 
أهمية للتعاون بين المطورين والعملاء أكثر من الأهمية التي توليها لتحديد عقود 
مفصلة وواضحة"". إن التواصل غير الرسمي بين فريق العمل والعميل قد يحل 
محل العديد من الوثاتق المكتوبة» حتى العقود التفصيلية. 

3. برمجية عاملة تفوق أهمية التوثيق : إن العمليات الإضافية أو التوثيق 
هو أحد آهم مصادر الهدر في تطوير البرمجيات؛ إذ تستهلك الأعمال الورقية 
الموارد وتبطى من زمن الاستجابة وتخفي مشكلات الجودة وقد تتعرض للضياع 
أو تضعف أهميتها أو قد تصبح باطلة لتقادمها. عندما يكون العمل الورقي 
مطلوباً» من الضروري آن يكون قصيراً وذا مستوى متقدم وتنفيذه من دون 
الاتصال بالإنترنت. يركز بيان المنهجيات السريعة على فهم المنتج من خلال 
التعاون مع العميل وتسليم برمجية عاملةء وبذا تقل كمية الوثاتق المطلوبة. 

4 الاستجابة للتغيير تفوق أهمية اتباع خطة: «السرعة هي القدرة على 
الإنشاء والاستجابة للتغير بهدف تحقيق ربح في بيتة أعمال مضطربة». آما 
التغيير فهو فرص لمساعدة العملاء على تحديد الاضطراب في السوق بدلا من 
تحديد مشكلات التطوير. 


تشير أول قيمتين إلى إدارة المواره البشريةء في حين أن القيم الأخيرة في 
القائمة السابقة تشير إلى إدارة العمليات. 
من هله القيم» هناك بعض المبادئ المشثقة المشثركة بین جميم بیانات 
المنهجيات السريعة. أما المبادئ الرئيسة المدرجة في بيان المنهجية السريعة فهي 
ما یأتی : 
الي ٠‏ 
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© الأولوية الكبرى هي إرضاء العميل من خلال تسليم برمجية ذات قيمة 
مبكراً وباستمرار: يجب على مطؤوري البرمجيات تسليم العميل المنتج تدريجيا 
بدءاً من المتطلبات الأكثر أهمية. 


# الترحيب بتغيير المتطلبات» حتى لو كان ذلك في مراحل متأخرة من 
عملية التطوير. تسخر العمليات السريعة التغيير لصالح العميل: التغيير ليس 
بالأمر السيئ» لكن حالة طبيعية في مشاريع البرمجيات. لا يمكن منع التغيير 
الذي لا يمكن توقعه دائماًء وعليه فإن عماية التطوير يجب أن تستوعب التغيير 
ولا تحاربه. 


8 يجب أن يعمل المختصون بالأعمال والمطؤّرون جباً إلى جنب يومياً 
خلال المشروع: إن التعاون الوثيق بين فريق العمل والعميل هو طريقة للحد 
من المخاطر التي قد تعترض المشروع بما أنه يتم التحقق من صحة تفسير 
احتياجات العميل في كل خطوة من خطوات المشروع. بهذه الطريقةء يتم الحد 
من حالات إعادة العمل الناجمة عن سوء فهم المتطلبات» ويكون المطوؤرون 
على معرفة دائمة للاستمرار في الطريق الصحيح. 

8 تسليم برمجية عاملة بشكل متكررء قد تتراوح فترات التسليم من عدة 
أسابيع إلى عدة أشهر مع أفضلية لمقياس زمني آقصر: إن البرمجية القابلة 
للعمل هي الشيء القيم الذي يقدره العميل حتى لو لم تكن مكتملة. إن تسليم 
مجموعة من الوظائف المطلوب توفيرها في البرمجية دوریا ولیس مجرد نماذج 
يعطي العميل القدرة على استخدام المنتج مبكرا. إضافة إلى ذلك يزيد ذلك 
من وضوح حالة ووضع المشروع. 

« بناء المشاريع بالاستعانة بآفراد لديهم حافز للعمل: لا ينطبق 
بيان المنهجيات السريعة على الجميع؛ إذ إن المطورين الذين يملكون 
المهارات والحافر للعمل القادرين على العمل ضمن فريق هم عامل أساسي 
للنجاح. 


# وَذر لهم بيئة عمل ملائمة والدعم الذي يحتاجونه؛ ثِىْ بهم لتضمن 
إنجاز العمل : يجب على المدراء عدم التدخل في اجراءات فريق التطوير. إن 
الثقة والدعم اللذين توفرهما الإدارة لهي طريقة جيدة لدعم فريق عمل ذي 
مهارات ودوافع للعمل. 
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# أكثر الوسائل فعالية وكفاءة لنقل المعلومات لفريق التطوير هي التقاش 
المباشر وجهاً لوجه: حتى لو كان هناك العديد من طرق التواصل»› إلا أن 
التواصل وجهاً لوجه هو أكثر الطرق فعالية لمنع حدوث سوء فهم وتقصير الوقت 
المستنفد لتبادل المعلومات. 

© البرمجية العاملة هي المقياس الأوّلي على تقدم العمل : النتيجة المهمة 
الوحيدة للعميل هي تسليم برمجية عاملة. فلا أهمية إذا كان أنتج الفريق وثائق 
تصميم جميلة في حين أن المنتج لا يعمل أو أنه لا يلي احتياجات العميل. 
يقيس العميل مدى التقدم في المشروع بقياس عدد الوظائف المسلمة التي تعمل 
فعلياً. 


2: 


6 ترفع العمليات السريعة من التطوير المستدام. يجب أن يكون كفلاء 
المشروع والمطؤرون والمستخدمون قادرين على الحفاظ على وتيرة إلى أجل 
غير مسمى: يجب آن يتم تنفيذ تطوير البرمجيات من خلال تعاون ثابت 
ومستمر بين جميع أطراف المشروع وأصحاب المصلحة. إضافة إلى ذلك» 
يجب آن يكون جهد فريق التطوير ثابتاً مع الوقت» ومحاولة تجنب فترات التوتر 
والإجهاد غير الدائمة على المدى البعيده ما يۋثر في دوافع التحفيز وإنتاجية 
فريق العمل. 

© إن الانتباه المستمر للامتياز التقني والتصميم الجيد يحسنان من سرعة 
التتفيذ: المطؤرون المتميزون ينتجون برمجيات ذات مستويات متقدمة. 
المطوّرون المتميزون قادرون على إنشاء نظم يمكن تحسينها وصيانتها بما يقلل 
من الوقث والجهد اللازمين. 

# البساطة - فن إنجاز أكبر كمية من العمل غير المنجز - أمر ضروري : 
إن تحديد الشيفرة البرمجية غير المتطابة هو طريقة لتحسين كفاءة فريق التطوير. 
إن الشيفرة البرمجية الأكثر بساطة أسهل للكتابة والفهم والصيانة. إضافة إلى 
ذلك» البرمجة الأقل تعني احتمالية آقل للأخطاء» وتتطلب اختباراً آقل. 

6 تنشأً أفضل الهيكليات والمتطابات والتصاميم من فرق العمل ذاتية 
التظيم : فريق العمل هو الوحيد المسؤول عن المنتج كاملاً. ليس هثاك تثافس 
بين فرق العمل التي تركز على آنشطة محددة (آي التصميم والتنفيذ). يعمل 
جميع أعضاء الفريق لتحقيق هدف مشترك» وهو بالتحديد تحقيق رضا العميل. 
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يعكس الفريق كيفية أن يصبح أكثر كفاءة على فترات منتظمةء ومن ثم 
يعمل على ضبط سلوكه بتاءَ على ذلك : عملية التطوير ليست ثابتة. يجب على فرق 
العمل أن تحدد مجالات التحسين باستمرار وذلك باختبار وتقييم تقليات جديدة. 

تنفد المبادئ المدرجة ويتم التشديد عليها بطرق مختلفة في العديد من 
بيانات المنهجيات السريعة المتوافرة. لكن» التركيز على احتياجات العميل 
والتحسين المستمر هما المبدآن الأساسيان. 


إن أفكار العميل التي تقود الإنتاج والتحسين المستمر في العملية ليست 
بدعاً. فهي المفاهيم الأساسية لمبادئ الإنتاج باتباع منهجية مه[ ولمبداأ 
الإنتاج «في الوقت المناسب“"' الذي استخدم في شركة تويوتا عام 1960 في 
صناعة السيارات. إن بيانات المنهجيات السريعة هي تنفيذ لهذه المفاهيم في 
صبناعة البرمجيات ° . 


1 - 4 البرجة القصوى ۶× 


ريما تكون البرمجة القصوى هي أكثر المنهجيات السريعة شهرة. في الوقت 
الحاضرء هناك إصداران من ۴× معرفان فى طبعتين من كتاب )مه8 . لكن 
في هذا القصل سنأخذ بالاعتبار الإصدار الأولء وذلك لأنه الأكثر شعبية 
والأكثر قبولاً في مجتمع البرمجة. آما الثاني فهو الاقتراح الأحدث الذي قدمه 
کینٽ «(Kent Beck) dı‏ حیث یقترح تعديلات وتحسيناتٽ مهمة. لکن» لا يزال 
مجتمع البرمجة يناقشه» لذا فهو ليس متقبلاً على نطاق واسع. إضافة إلى ذلكء 
الإصدار الأول أكثر بساطة ويجب أن يكون نقطة البدء لأولئك الذي يسعون إلى 
بيانات المنهجيات السريعة للمرة الأولى. 

تعرّف ممارسات ۴× كوصف لعملية ناجحة يتبعها فريق ٥3‏ الذي طور 
نظام رواتب ضخماً لشركة كرايسلر. قاد كينت بيك فریق ٥3‏ بنجاح» حیث 
تمكنوا من تسليم نظام عامل بعد سنتين» في حين كان فريق العمل الأول غير 
قادر على تسليم آي شيء في آربع سنوات عمل. 

(8) استراتيجية لإدارة الملخزون» تسعى إلى تحسين العائد على الاستشمار من الأعمال والجودة والفاعلية 
عن طريق تخفيض المخزون المستخدم في العمليات وما يرتبط به من تكاليف. وهذا يعني أن المكونات والعناصر 


اللازمة لعملية الإنتاج قد تصل في الوقت المناسب ليختار العمال منها واستخدامها. وهذا يساعد في الحد من 
التخزين والحرد وتكاليفهما إذ إن المخزون يصل في الوقت المناسب (المترجم). 
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تعرف منهجية ۴× تسلسل مبادئ وممارسات التطوير بالتفصيل. لکن لم 
يعرف هذا التسلسل بصورة مباشرة لكنه اشتق من القيم والمشحكمات التي 
تعتبر أساس المنهجية (الشكل 1-11). 


آما قيم متهجية ۴× فهي كما يآتي : 
© البساطة: يجب أن يكون النظام بسيطاً ما أمكن لتلبية احتياجات العميل. 


لكن ليس أكثر بساطة. تنفيذ الميزات المطلوبة لكن يجب عدم شمول ميزات 
تدعم المتطلبات المستقبلية التي قد تصبح متطابات حقيقية. 


ه الشواصل: يجب أن يحسّن كل شيء من التواصل بين العملاء 
والمطؤرين وبين المطورين أنفسهمء وبين الشيفرة البرمجية المصدرية والقارئ. 
إن التواصل الفاعل يقلل من سوء الفهم والحاجة إلى بذل الوقت والجهد في 
التوثيق الرسمي والمكتوب. 


الانطباعات وردود الأفعال : يجب أن يحصل المطوّرون على انطباعات 
العملاء وردود أفعالهم بسرعة ت على ۶ کافة المستويات. يجب أن يحقق العملاء 
والمدراء والمطرون فهماً مشتركاً للهدف من المشروع وعن الوضع الحالي 
للمشروع وما يحتاجه العملاء أولاًء وما هي آولرياتهم» وما يستطيع المبرمجون 
عمله وفي آي وقت. وهذا يتحقق بوضوح عن طريق التواصل. يجب آن يكون 
هناك تغذية استرجاعية فورية من العمل الذي ينفذه القائمون على المشروع» أي 
من الشيفرة البرمجية التي يتم إنتاجها. يجب أن تنفق نسبة كبيرة من جهود 
البرمجة (حوالى 50 في ا في تطوير الاختبارات المؤتمتة. بهذه الطريقة 
تكون جودة النظام المطرّر عالية على تحو منطقي. 


ه الشجاعة: يجب آن يتحلى كل شخص ذي علاقة بالمشروع بالشجاعة 
(والحق) لعرض وضعه في المشروع. ي يجب أن يكون لدى الجميع الشجاعة 
والفكر المنفتح والسماح للجميع بالتحقق من عمله وتعديله. یجب آن لا یتم 
عرض التغيير بترهيب ويجب أن تكون لدى المطررين شجاعة للعثور على 
حلول أفضل وتعديل البرمجة عندما يكون الأمر لازماً ومجدياً. إن استخدام 
الأدوات الصحيحة وحزم الاختبار الشاملة يمن البرمجة وتجربة حلول جديدة 
من دون خوف. وهذا يعني أنه من السهل اختبار ما إذا كان التعديل ينتج 
أخطاءء» ومن السهل الرجوع إلى الإصدار الأسبق القابل للعملء إن لزم الأمر. 
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| س 
الشكل (1-11) : القيم والمشحكمات والبادئ في منهجية ۴× 


أما متحكمات منهجية ۴× فهي كما يأتي : 


# التركيز على القيمة: بجب أن يركز المطؤرون على ما يوفر أعظم قيمة 
للعميل. تحدد أولويات التطوير بناء على أولويات العميل؛ وليس على القضايا 
الثقنية الي لا توفر آي قيمة للعميل. 

© تدفق ثابت للأنشطة: پجب أن يعمل فريق التطوير على نسق ثايت 
وتجنب أعباء العمل الكثير أو القليل. 


® لا عيوب: العيوب الثي قد تكون صغيرة وبسيطة اليوم تصبح كبيرة 
وتصعب إدارتها مستقبلا. يجب على الفريق إصلاح جميع العيوب المعروفة والتحقق 
من آنها لن تظهر ثانيةً في الإصداراث المستقبلية من خلال الاخثبار المؤتمث. 


الروابط بين القيم والمتحكمات ميّنة في الشكل 11 - 2. 


الانطباعات 


الشجاعة ي غياب العيوب 
الشكل (2-11) : الروابط بين القيم والمححكمات في ۶× 
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إن التركيز على القيمة واضح في البساطة . يقوم الفريق بتطوير الميزات 
المهمة للعميل فقط. وهذا التركيز حاضر في التواصل مع العميل لاستخراج 
المتطلبات وأولوياتها. إضافة إلى ذلك الانطباعات وآراء العميل هي متحكم 
من متحکمات التطوير» بما إن العميل پحدد آولويات ما پرید إضافته و/ أو 
3 تحسينه في المنتج. 

إن التدفق الثابت واضح في الانطباعات» حيث يطلب المطؤرون من 
العملاء تحديد أولوياتهم ويماوضون العملاء على مقدار الوظائف التي یجب 
تسليمها بشجاعة» ومن دون أي خوف من اتهام من جاتب العميل أن المطوّرون 
لا یعملون بشکل کافِ. 

إن استهداف «غياب العيوب» يتطلب بساطة في التصميم لتجنب ظهور 
العيوب ویتطلب الانطہاعات من الأدوات والعملاء للحد من الأخطاء الموجودة 
وكشف عدم التوافق مع رغبات العملاء. إضافة إلى ذلك إن التواصل بين 
المطوّرين والتجرؤ على اختبار الشيفرة البرمجية ضمن ظروف قاسية يساعد 
بقعالية على الحد من العيوب. 

من القيم والمتحكمات» تحدد منهجية ۴× مجموعة من الممارسات» هي 
كما يتي : 

© لعبة التخطيط (عصa‏ ع«ن«مها۴): يجب أن يتم التخطيط من قبل 
المطزر والمدراء والعميل معاً, يقوم ھؤلاء الأطراف الغلاثة معاً بكتابة 
سيناريوهات المستخدمين للنظام؛ ثم يحدد العميل الأولويات» في حين يحدد 
المدير الموارد اللازمة للمشروع؛ يقوم المطزرون بالإبلاغ عما يعتقدون آنه 
مجد. يجب أن يكون التواصل بشأن الخطة نزيهاً ومتفتحاً. 

6 اللإصدارات القصيرة (e8یےءاء۸ ٥۲٤‏ ط5): يجب أن يتواصل تطویر النظام 
بتوفير إضافات صغيرة ة ضصمن إصدارات متكررة يجب أن يستخدمها العميل 
لتزويد انطباعات مفيدة. 

© الاستعارة (0۲طمpهاءM):‏ يجب أن يستىخدم أفراد فريق المشروع جميعاً 
لْغة اصطلاحية مشتركة بين المطررين والعملاء والمدراء بحيث يتمكن المطرّروك 
من فهم مجال المشكلة بشكل أفضل»ء وبحيث يتمكن العملاء من تقدير الحلول 
التي يقدمها المطرّرون بصورة أفضل كذلك. يمكن بناء هذه اللغة الاصطلاحية 
بناءَ على التناظر الوظيفي الكلي للنظام قيد الإنشاء. 
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e‏ تصميم بسيط (دعنوء عامصا8) : يجب الحفاظ على بساطة النظام 
وتطويره تدريجيا بتطور النظام نفسه 

© البرمجة المدقوعة بالاختہار :)Test-Driven Development)‏ يجب أن 
تكتب سيناريوهات الاختبار مع العميل قبل بدء البرمجة الفعلية؛ ي يجب أن تغطي 
هذه السيناريوهات جمیم جوانب ومظاهر النظام ذات العلاقة. بهذه الطريقة 
تفيد سيناريوهات الاختبار كطريقة لضمان أن تحقيق المتطلبات عل ميعة 
مواصفات رسمية لسلوك النظام. 


© تغيير تصميم البرنامج من دون التأثير في التتائج (ع«ا۲هاءه!»۸): يجب 
ا يتم مراجعة الشيفرة البرمجية على نحو متكرر للحفاظ على بساطتها وجعلها 
أسهل للقهمء وتكون القيود فيها واضحة بحیث (أ) يجب أن ية يتحقق هذا 
التبسيط من خلال الاختبار أولا (ب) ږ یجب آن يتم اعتماد التبسيط عتد مروره 
خلال جميع الاختبارات الجديدة فقط» ول چب آن پتم عمل التبسيط من 
خلال مطورين اٿئين (ثنائي). 

e‏ البرمجية ا الشنائية (Pair Programming)‏ ; يجب أن يعمل المبرمجون في 
البرمجية في حين يقترح اک الأفكار ويتحقق من الشيفرة البرمجية التي يتم 
کتابتها. 

© ملكية جماعية للشيفرة البرمجية :)Coleective Code Ownersh¡p(‏ يچپ 
أن يكون لكل فرد في فريتق البرمجة القدرة على الوصول لأي جزء من الشيفرة 
البرمجية مما کتبه مبرمج آخر. کما پجب آن یکون قادرا على تعدیله واعتماده 
الجديدة التي تمر من خلال الاختبارات الجديدة والقديمة فقط› و(ج) العمل 
في مچموعات لنائية. 


© التكامل المستمر (٥10اraٍe )Continuous nt‏ : يجب أڻ يتم دمج الشيفرة 
البرمجية بصورة ة مستمرة لضمان آن جميع الأجزاء تتتاسب مع بعضها البعض 
بسلاسة. 


© ارہ بعون ساعة عمل سبو عي :(Forty-Hour Work Week)‏ ج ùÎ‏ 
يستمر المشروع على وتيرة مستدامة ص خطوط التدفق الثابت الذي تدعو إليه 
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منهجية صمم1. لذاء» قد تكون جهود العمل الكبيرة مقبولة ومحتملة لأسبوع أو 
اثنين على مدى المشروع» لكن يجب أن يكون توزيع الجهد سهلا ولا يتجاوز 
ما يحتمله الموظف في الظروف الطبيعية» آي 40 ساعة عمل في الأسبوع. 

© تواجد العميل في موقع العمل (erصo :)0«-5ite Cust‏ یجب آن 9 ن 
وصولية العميل والمطورين سهلة» ويستحسن تواجدهما في الموقم نفسه إ 
كان ذلك متاحاً. بهذه الطريقة» سيضمن العميل أن المطورين بس ب 
الخطة وآن بإمكانهم استلام اتطباعات العميل بسرعة. 

معايير البرمجة (sلءةلمهاS‏ ع«iله٥):‏ يجب أن تكتب الشيفرة البرمجية 

بطريقة تى ليها من قبل جم أعشاء فريق الرمجة اتعزير اتقام والمارئة 
بسهولة. e4‏ ما هر المعيار الذي يچب اعتماده علماً أن وچود معیار آمر 
منطقي ومقبول للجميع› لكن يجب وجود معیار. 

المتحكمات والقيم والممارسات مترابطة بإحکام في منهجية .XP‏ وهله 
الروابط موضحة في الجدول 1-11. 


الحدول (1-11) 
العلاقات بين المتحكمات والقيم والممارسات 


التواصل أ البساطة | الانطباعات 


لعبة التخطيط 
الإصدارات القصير 


الاستعارة | الاستعارة | 
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LS E EA E E KS LP 


SSG 
السمل‎ 


إسايرايية __ ]| 7 | ]|7] ]|__| 


4-1 - 1 بنية فرق العمل في منهجية ۲× 

إن حجم وبنية فريق العمل أمران مهمان لتطبيق ۴× بنجاح. صممت 
منهجية ۴× للعمل مع الفرق الصخيرة (من مبرمجين إلى 12 مبرمجاً) يتواجدون 
في غرفة واحدة. إن حجم الفريق الصغير والموقع المشترك في غاية الأهمية 
لتطبيق بعض الممارسات بصورة صحيحة كلعبة التخطيط والملكية الجماعية 
للشيفرة البرمجية وتواجد العميل في موقع العمل وغير ذلك. إذا لم تتحقق هذه 
المتطابات» فقد تساعد بعض المنهجيات السريعة الأخرى كمنهجية 8٤C۸ 0M‏ 
والمنهجية الكريستالية. . . إلخ. 

يرتبط مستوى السرعة غالبا بحجم فريق البرمجة. التواصل المباشر والتوثيق 
المحدود أمران ممكنان في الفرق الصغيرة فقط. على العكس من ذلك» عندما 
يكبر الفريق» يكبر مستوى التفقات العامة أيضاً. تتضمن النفقات العامة : 

® التوئيق. 

الاتصالات الوسيطة (من خلال الوسائط كالورق). 

لمشاركة المعرفة وتتبع حالة المشروع» يتطلب الأمر المزيد من التوثيق 
لأنه لا يمكن إجراء التفاعل المباشر بين العديد من الأطراف بعد الآن 6). 
إضافة إلى ذلك؛ تزيد أهمية التوثيق ويصبح طريقة لتحسين تشارك المعرفة. في 
هذه الحالة» لا تكون الشيفرة البرمجية كافية» ولا يكون التواصل المباشر بين 
فريق التطوير والعميل ممكنا نظرا إلى حجم الفريق. 

في منهجية ۴× هناك ثلاثة عناصر أساسية : 

. (The Customer) Jınail .1 

.(The Developer) رjط¦nll‎ .2 


„(The Manager) رıدnll‎ .3 
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تكون مشاركة العميل كبيرة في عملية التطوير» وغالباً ما يكون عضواً 
في فريق التطوير. إن وجود العميل أمر مهم في «XP ٠‏ وذلك أن معظم 
المشروع كله ولا 5 تقتصر على بدايته فقط. وعليه» غالباً ما يطلب فريق 
التطوير من العميل الإجابة عن بعض الاستفسارات في ما يتعلق بالمتطلبات 
والتحقق من صحة التنفيذ. 

إن تواجد العميل يقلل كمية التوثيق المطلوبة لوصف المتطلبات بالتقصيل› 
كما إن مساهتمه المباشرة عامل آساسي نجاح المشروع. إضافة إلى ما تقدم؛ 
يوفر العميل رأيه للمطورين لتحديد أي مشكلات محتملة مبكراً في عملية 
التطوير ولتجنب التأثير الكبير في جدول المشروع الزمني. 

آما النشاطات الرئيسة للعميل فهي كما يأتي : 

© تحديد الوظائف المطلوبة من المنتج. 

® تحدید أولويات هله الوظائف. 


8 تحدید اختبارات القبول (بمساعدة المطؤرين). 


المطوّرون في منهجية ۴× ليسوا الأشخاص المسؤولين عن تنفيذ المنتج 
فقط ؛ فهم يتفاعلون مع العميل عن قرب ويوفرون البرمجية التي تعمل وفقا 
لمتطابات العميل ويقومون بجمع آراء العميل وانطباعاته ذات القيمة. لذاء لا 
يتطلب الأمر أن يكونوا مطرّرين جيدين قادرين على العمل ضمن فريق فحسب»› 
بل يجب آن يكونوا قادرين على التواصل مع العميل بلغته. 

يجب على المطورين أن پوفروا برمجية عمل ذات جودة عالية للعميل 
في کل فترة برمجية دورية وجمیم الاتطباعات ذات ألقيمة. هله المنهجية قَيْمة 
لكل من المطررين والعملاء . يمكن أن يجمع المطزرون معلومات مفيدة لتجنب 
تتفي ميزات غير مفيدة أو خاطثة» وهذا يقلّل من الوقت المستغرق لتتفيذ 
الميزات المفيدة؛ بإمكان العملاء اختبار المنتج البرمجي بأنفسهم بعد بضعة 

آما النشاطات الرئيسة للمطوّر فهي كما يأتي : 

© تحليل وتصميم واختبار ودمج النظام. 
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© تقييم صعوبة تنفيذ المتطلبات التي حددها العميل. 

8 العمل في فرق ثنائية؛ آي مبرمجين ولوحة مفاتيح واحدة: آحدهما 

8 مشاركة الشيقرة البرمجية مع المطورين الآخرين في الفريق. 
حيث إنه من الممكن وجود تفاعل مثمر بين فريق التطوير والعميل. يمكن 
للمدراء تحقيق هذا الهدف بتحديد آفضل الأشخاص الذين سيضمهم الفريق 

غالباً ما يعمل فريق العمل في المنهجيات السريعة وفقاً لعقود تتصف 
هذه الطريقة على قدرة المدير على تحديد العقد الذي يحقق رضا العميل ويتيح 
مرونة في عملية التطوير. 

آما أهم الأنشطة التي يقوم بها المدير فهي كما يأتي : 

۵ وضع بنود التعاقد والتفاوض مع العميل عن تطبيق ممارسات منهجية 

التطوير السريعة. 

8 مساعدة العملاء والمطوّرين ليصبحوا فريقاً متماسكاً. 

® المساهمة في تيسير تنفيذ مهام العملاء والمطررين. 

العامل الأساسي للنجاح في مشروع ۴× هو التزام أعضاء الفريق - وليس 
التزام المطورين فقط» لكن التزام المدراء والعملاء. يجب آن يدعم المدراء 
فريق التطوير وإنشاء بيثة عمل لتطبيق ۴× بطريقة تؤتي ثماراً. يتوجب على 
العملاء التراجد للإجابة عن أسثلة واستفسارات فريتق التطوير وتقييم الحلول 
المقترحة. 

1 - 4 - 2 إدارة المتطلبات في ۲× 

المتطلبات هي الأساس لكل المنتجات البرمجية؛ إن تحديد 
المتطلبات وإدارتها وفهمها من أهم المشكلات التي تواجهها جميع منهجيات 

)62 : 
التطوي 7" . 
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الحدول (2-11) 
آهم أسباب فشل المشروع 


-حسب دراسة آجرتها مجموغعة Pgtandish‏ « خمسة من آصل ثمانية 


عوامل لفشل المشروع تتعلق بالمتطلبات (انظر الجدول 11 - 2): متطلبات غير 
محتملة» ومشاركة العميل ضعيفة» وتوقعات غير واقعية» وتغيير فى المتطلبات»› 
ومتطابات غير مفيدة. 

في ۲×› لا تنقذ عملية جمع المتطلبات في بداية المشروع فقط» بل هو 
نشاط يدوم على مدى المشروع كاملا عملياًء يمكن آن يغيّر العميل كلا من 
المتطلبات وأولوياتها ني كل فترة برمجية تكرارية في المشروع بعد تقييم النظام 
الذي سلمه فريق التطوير في الفترة البرمجية السابقة. هذه الآراء والانطباعات 
المستمرة ضرورية للحفاظ على مسار المشروع وتسليم برمجية تكون قادرة على 
تلبية احتياجات العميل فعلياً. 

تعترف منهجية ۴× آن تغير المتطلبات هو مشكلة ثابتة في معظم المشاريع 
البرمجية؛ لذاء دعم مشل هذا التغيير آمر ضمني في العملية كعامل 5 a0,‏ 
إضافة إلى ذلك لا تحاول منهجية ۴× تو قع التغيير أو الاحتياجات المستقبلية› 
بل تركز فقط على الميزات التي يدفع العميل مقابل الحصول عليه تتجنب هله 
الطريقة تطوير هيكلية عامة جداً تتطلب جهوداً إضافية . 
ما يعرف بسيتاريوهات المستخدمين (ءاءه)5) والاستعارات (Metaphores)‏ . 


سجل مهام الاستخدام (رإها8) هي وصف لسلوك النظام الوظيفي. وهي 
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مشابهة تماماً لحالات الاستخدام» لكنها تركز على الوظائف الجزئية فقط ؛ بناءٌ 
على ذلك» يمكن تقسيم حالة الاستخدام إلى العديد من سيناريوهات 
المطورين. يحدد العميل أولويات سيناريوهات المستخدمين في حين يقَيّم 
المطوّرون مدى صعوبتها والجهد اللازم لتنفيذها (نقاط سجل المهام). 
يجب أن تكون سجلات المهام الفاعلة: 
ایر اشن اال :انون 
© مكتوبة بلغة عادية. 
8 مختبرة (يجب أن يكون الاختبار مكتوياً من قبل العميل بمساعدة 
المطرّرين). 
6 مستقلة عن السيناريوهات الأخرى لأكبر درجة ممكنة (على الأقل عن 
السيناريوهات الموضوعة في نفس الفترة البرمجية التكرارية). 
6 لا تتجاوز أسبوعَي عمل (آي طول الفترة البرمجية التكرارية في ۴). 
يبيّن الشكل 11 - 3 سجل مهام الاستخدام نموذجية 


سوس 
TTS‏ 


2 has to input hisher nickname and password | to login the system, lf 
th 


combination of the nickname and pas an etror 
mèssage will show, and th SsSword 
agbin, اوک‎ 
Pefsonal page and bi etonality are avaltabte oily when the user logs 


sudeessfully, Administrative functionafîty is available only when the user | 


with administrative privileges logs in successfully. 
| 


1 شیر جه الام من قل ددمت | اختبار قبول سجل المهام 
الشكل (3-11): تركيب سجل المهام 
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يعمل المطزرون على تقييم الجهد اللازم لكل سيناريو على ساس 
خبراتهم وعلى أساس المشروع المستمر. قد تتطلب سيناريوهات المستخدمين 
الكبيرة تحقيقاً عميقاً للوصول إلى جدواها والجهد اللازم. في هذه الحالات؛ 
يطبق المطرّرون حلول ام5 التي تعتبر تحقيقاً أكثر دقة وتطبيقاً تجريبياً لهيكل 

يتم تحديد الجهد في نقاط سجل المهام التي يجب آن ترتبط بمقدار محدد 
من الجهد مثلاً يوم واحد لعمل زوج من المبرمجين (إذ يعمل المبرمجون دائماً 
في مجموعات ثنائية). إذا كان يبدو أن سجل المهام تحتاج أكثر من أسبوعين 
اثنين» يطلب من العميل تقسيمها. 

يرفق مع كل سجل مهام اختبار قبول يحدد عندما يتم تطبيق الوثيقة بصورة 

8 يجب أن يكون اختبار القبول الفاعل : 

# يتحقق من أن سجلات المهام قد طبقت بصورة صحيحة. 

۵ يكون مكتوباً من قبل العميل بعد كتابة كل سجل مهام. 

8 يكون هناك اختبار قبول واحد على الأقل لكل سجل مهام. 

۵ یتحقق من متی يصبح بالإمکان اعتبار سجل المهام مكتمل بحيث يتم 

البدء ببرمجة سجل مهام جديدة. 

نوع من اللغة المشتركة يمكن فهمها بسهولة من الطرفين» ويجب أن تساعد هذه 
الاستعارات في التواصل من دون استخدام الكثير من اللخة التقنية التي قد ينتج 
منها سوء فهم إذا كان مجال التطبيق غير معروف لجميع أفراد الفريق. 


1 - 4 - 3 مقدمة لعملية التطوير بمنهحية ۲× 


تحدد منهجيات التطوير التقليدية كمنهجية الشلال (الشكل 4-11) مراحل 
عملية التطوير (التحليلء والتصميم والبرمجةء والاختبار) التي تمر عبرها 
مراحل الانتاج. تم تعديل هذه الهيكلية الصارمة بطرق مختلفة بعمليات تطوير 
أخرى كالمنهجية الحلزونية وطرق أخرى عديدة. 
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الشكل (11- 4): عملية منهجية الشلال 


تنظم منهجية ۴× عملية التطوير بطريقة مختلفة جذرياً (الشكل 5-11). إن 
التحديد الرسمي للمراحل لم يعد حاضراً بعد الآن» وتنظم عملية التطوير في 
فثراث برمجية تكرارية يعمل المبرمج من خلالها على إنتاج شيء ذي قيمة 
بالنسية إلى العميل. يقوم المبرمج بإجراء يعض التحليل وبعض التصميم 
والاختبار لكل متطلب من متطلبات العميل التي حددت في سجلات المهام 


بالإضافة إلى كثابة الشيفرة البرمجية. 
تحلیل 


او = برمجة 
چ سے اختبار 


رمن 


الشكل (5-11): عملية ۴× 
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لهذه الطريقة بعض النقاط المهمة» إذ يتم تنفيذ الاختبار قبل كتابة الشيفرة 
البرمجية لان منهجية ۶× تستخدم طريقة الاختبار أول* : يتم كتابة سيناریوهات 
الاختبار قبل كتابة الشيفرة البرمجية التي تحقق تلك السيناريوهات. ليس صحيحاً 
أن ليس هناك تحليل أو تصميم في ۶× بل إن هذه المنهجية تنشر التحليل 
والتصميم خلال عملية التطوير كلها ولا تركز عليهما في بداية المشروع فقط. 
تتيح هذه الطريقة للمبرمجين التجاوب بسرعة لطلبات التغيير والحد من هدر 
الموارد التي قد يتسبب عن تطبيق متطلبات خاطعة , 


1 - 4 - 4 مقارنة منهجة ۲× بالمنهجيات الأخرى 
يقارن الجدول 3-11 بعض المنهجيات المعروفة لدى مهندسي البرمجيات 
فی تطویر البرمجيات التقليدية› بمبرمجی لهاست ومبرمجی ۲× . 


الحدول (3-11) 


مقارنة ۴× بالمنهجيات الأخرى 


مانس ریات ية __ | _ مب 0 


«علي أن أكشب جميم التوثيق بطربقة 
كاملة بحيث يكون الأشخاص مستقبلاً 
قادرين على فهم ما جري٤.‏ 


«علّ أن أعمل بجنون لإنجاز المشروع 
خصوصاً عند اقتراب موعد العسليم. 
البرجة عملية شاقة1. 


«الشيفرة البرجية هي ملكي و-حدي ولا 
يُسمح لأي کان بلمسها!. 


«في النهاية› نقوم بإجراء التكامل. 
سيکون ذلك صعباًء لذاعلينا أن تحدد 
بروتوكلات دمج وتكامل مكمة 
وتوثيقها بأكثر تفاصيل مكنة). 


٣۳‏ حتاج آي توثیق؟. 


«علي أن أممل بجنون 
لإنجاز المشروع عند اقتراب 


موعدالتسليم فقط. 


البرجبة عملية متعةا. 


«الشيفرة ة البرمجية هي ملكي 
وحدي ولا ي يسمح لاي کان 
بلمسها!. 

«هي النهايةء تقوم بإجراء 
التكامل. مامن مشكلة»› 
الأمر سهل: سيستغرق 
الأمر .٤5‏ 
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EE 
قبل البده بالبرجة).‎ 

«عليّ أن أكتب الشيفرة البرجية بحيث 
يكون الأشخاص مستقبلاً قادرين على 
فهم ما جري. أحتاج إلى كتابة بعض 
التوثيق الذي قد ناجوه فقط). 

«جب أن أعمل بحيث لا يزيد ذلك 
على 40 ساعة أسبوعياً لإنجاز المشروع 
خصوصاً عند اقتراب موعد التسليم» 
مع الحفاظ على وتيرة ثابتة وعقل 
متجدد. البر ية عملية متعةا. 
«الشيفرة البرمجية هي ملك للفريق 
ويسمح للجميع بتعديلهاء وهي تتح 
استمرارية عمليات الاخبار!). 

«علينا أن نقوم بالدمج وتكامل النظام 
پومباً على الأقل » بحيث لا يكون هناك 
أي مشكلة في النهاية). 


جب أن يرى العميل نسخة عاملة | ١إذا‏ كان بالإمكانء جب أن | جب أن يكون العميل : (أ) متفاعلاً 
ونظيفة من المنتج» من الأهمية بعكان | يرى العميل نسخة نائية من | مع المنتج الذي يتم بناؤه ومع فريق 
موازنة التواصل مع العميل بحيث لا | المنعج؛ من الأهمية بمكان | العمل» و(ب) تواجد غثل عن العميل 
يكون هناك إهدار للوقت). «الحد ما أمكن من التواصل | في الموقع إن أمكن). 
مع العميل بحيث لا يكون 
هاك إهدار للرقت). 
«إن لم یکن معطلاًء لا تلمسه». «حتی لو کان معطلاء لا | «حثی لولم یکن معطلا قم بتغییر 
تلمسه! حاول إخفاءه٤.‏ |تصميم البرنامج من دون التأثير في 
النتأئج بصورة ثابتة! استخدم 
سيناريوهات الا خثبار لضمان آنك لا 
تنتج عيوباً غير مرغوب فيها). 
«خطط کل شیء جیدا مقدماً بحیٹ لا | ٥لا‏ تخطط کل شیء؛ لکن | «خطط كل شىء يمكنك توقعه وکن 
يكون هناك حاجة إلى إجراء تغيير! | حاول أن لا تجري تغييرا! | مستعداً للشغيير! دث التغيپرات 
فالتغبير دليل واضح على التخطيط غير | فالتغيبر هو دلبل واضح على | طبيعياً في المشاريع البرجيةا. 
الكافي أو التخطيط السي). انزعاج العميل أو المدير؟. 


س 
للتعامل معه!). 


1 - 4 - 5 آلياث الشحكم في منهجية ۲× 
تم ضبط آي نوع من عمايات الإنتاج من خلال آليات تحكم تحدد كيفية 
مزامنة الأنشطة المختلفة لتحقيق هدف مشترك. 


ثمة طريقتان رئيستان للتحكم بعملية الإنتاج : تحكم خارجي وتحكم ذاتي. آما 
عملية التحكم الخارجي فتحدد القوانين المضافة للعملية. وهذا يعني أن العملية 
تفسها لا تتضمن تلك القوانين» بل إنها أضيفت لاحقاً لتنفيذ آلية تحكم. على العكس 
من ذلك فإن التحكم الذاتي يحدد قوانين التحكم كجزء من العملية. وهذا يعني أن 
العملية مصممة بحيث تكون آلية التحكم ضمنية في العملية ولا يمكن فصلها. 

تستخدم أساليب هندسة البرمجيات التقليدية التحكم الخارجي أكثر. على 
العكس من ذلك» تستغل المنهجيات السريعة منافع السيطرة الذاتية. وهذا يعني 
أن العديد من ممارسات المتهجيات السريعة مصممة لإجبار المطوّرين على 
التنسيق من دون الطلب منهم ذلك صراحةء ما يحد من الأنشطة الإنتاجية غير 
المباشرة اللازمة للتنسيق فحسب. بناءَ على ذلك» يمكن أن يركز المساهمون 
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في المشروع على أعمالهم الجوهرية في حين يتم حل المشكلات حين ظهورها. 
غني عن القول إن هذا محفز واضح للجودة: إذ إن آي شيء لا يتطابق مع 
معايير مراقبة الجودة لا يمكن تمريره أو قبوله. 

يتضمن بيان المنهجية السريعة تحكماً خارجياً في جميع مبادئه. إن التحكم 
الذاتي أكثر كفاءة من التحكم الخارجي بكثير؛ لكن قد يكون من الصعب 
تحقيقها. تحاول المنهجيات السريعة تبني طريقة يقة تطوير تكيفية. يكون فيها 
التحكم ضمنياً بدلاً من إضافة التحكم للعملية لاحقاً. وهذه الطريقة هي إحدى 


(22) 


معتقدات الإدارة بمنهجية ٣4ء1‏ 

حسبما أورد كل من مالون #«ملة١‏ ودهاومسهإ٥#‏ فإن الطريقة الوحيدة 
التي يمكن آن تكون فيها مهمتان معتمدتين على بعضهما البعض هي من خلال 
نوع من المصادر المشتركة. وبالتالي فإن هناك للاثة أنواع من الاعتمادية بين 
المهام» وهي 

© التحكم المتعاقب: يظهر عندما تُنشئ مهمة ما مصدراً (مخرجا) تتطلبه 
مهمة آخرى ا في هذه الحالةء يكون هناك تبعية تصدرية بين 
المهمتين ما يتطلب ترتيب التنفيذ بصورة صحيحة"“ (الشكل 6-11). 

8 المصادر المشتركة: تظهر عندما تشارك مهام عديدة بعض المصادر 
الممحدودة”“ (الشكل 7-11). 

نتائج عامة: وتحدث عندما تساهم مهمتان في إنشاء النتائج ج نفسها 
(المخرجات). يمكن أن تكون هذه التبعية ذات تأثيرات إيجابية أو سلبية. فى 
الواقعم» إذا كانت كلتا المهمتين تؤديان الشيء نفسه من دون قصد» فقد ينتج 
من ذلك مشكلة في التكرار أو هدر المصادر. ومع ذلك يمکن أن تؤثر 
المهمتان في جوانب مختلفة من المصادر المشتركة. وهذه هي الحالة في معظم 
المشاركين لتحقيق هدف مشترك (الشكل 8-11). 

إن آلية التنسيق الأسهل هي آلية تسلسلية. في هذه الحالةء تكون الأنشطة 
مستقلة تماماً وترتبط فقط من خلال وثائق الإدخال والإخراج. آما آلية تنسيق 
المصادر المشتركة فهى أكثر تعقيداًء ذلك ul‏ يجب أن تحدد أولويات الأنشطة 
لتخصيص المصادر المشتركة للنشاط الأكثر أهمية. أما الآلية الأصعب» فهى 
التنسيتق من خلال التتائج المشتركة. في هذه الحالةء يجب أن تعمل الأنشطة مع 
بعضها البعض لإنتاج ا ئج نفسها. 
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الشكل (11- 6): التحكم الحعاقب 
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الشكل (11- 7): مصدر مشترك 


الشكل (11- 8): غخرج (نتيجة) مشترك 
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إن تقنيات هندسة البرمجيات التقليدية قائمة بمعظمها على التحكم 
الخارجى والتنسيق المتعاقب. على عکس ذلك› تقوم المنهجيات السريعة و 
۴×على التحكم الذاتي وتنسيق المخرجات المشتركة. يسرد الجدول 4-11 آليات 
التحكم المستخدمة فى ممارسات منهجية ۴× . 

بالتوازي مع التحكم بالعمليات» هناك مشكلة تنظيميةء حدد نطمں ١#‏ 
ثلاث آليات كبرى تعتمد على القدرة على قياس النتائج والمعرفة المتاحة في 
بعض العمليات (الشكل 9-11) : 

8 سلوكي: تستخدم هذه الآلية عندما تكون العمليات اللازمة للإنتاج نتائج 
محينة واضحة وشفافة. وهذا عمل مکتبي نموڏجي. 

8 حصيلة: تستخدم عندما يكون بالإمكان قياس مقدار و/أو كمية النتائج. 
وهذه مهام احترافية أو تقنية بسيطة يمكن تنفيذها بالاستعانة بمصادر خارجية. 

© زمرة: تستخدم عندما لا تکون العملية واضحة وياس التتائج غير سهل. 
وهذا وضع مثالي في معظم الأعمال القائمة على المعرفة المعقدة حيث يمكن 

نتاتج العمل النهائية لفترة محدودة فقط. 


الحدول (4-11) 


الاستعارة خار ادي 
ذاي 
تغيير تصميم البرنامج من دون التأثير في النتائج ذاتي 


ذاق 
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إن فهم عملية التطوير مرتفع في تقنياث التطوير التقليدية القائمة على 
الشخطيط المسيق حيث يكون هناك تحديد للمهام والإجراءات والأدوار. على 
سبيل المشال» في منهجية الشلال يكون لكل مرحلة من مراحل العطوير 
مخرجات واضحة وإجراء يجب لكل مرحلة اتباعه من المدخلات للنتائيح (هذه 
قضية مختلفة تتأثر بالظروف). 


الشكل (9-11): آنواع التدظيم والتحكم 


تعثرف المنهجيات السريعة بصعوبة فهم عملية تطوير البرمجياٽت وقياس 
النتائج. لذا قإنه بفضل الإشراف على المصادر بعنهجية الزمرة. هذا آمر واضح 
في بيان منهجية التطوير السريع» حيث يعبر «التشارك؛ أكثر أهمية من 
«التفاوض؟ وبعتبر «التفاعل» أكثر أهمية من العمليات؛. 


1- 5 دعم الأدوات في منهجية ۲× 

هناك العديد من الأدوات التي تدعم التطوير باستخدام منهجية ۴×. لكن 
يفضل العديد من فرق التطوير باستخدام هذه المنهجية استخدام الأدوات 
التقليدية والأقل تعقيداً من الناحية التقنية كاستخدام الأوراق والأقلام والألواح 
والاجتماعاث المباشرة حيث ياتقون وجهاً لوجه. 


على سبيل المثال؛ يشم كثابة سجلات مهام الاستخدام على قطع صغيرة 
من الورق بحجم البطاقات البريدية ويثبتوتها على لوح باستخدام الدبابيس. 
يقسم اللوح إلى ثلاثة أقسام: سجلات المهام التي بجب تنفيذهاء وسجلات 
المهام قيد التنفيذ» وسجلاث المهام المنجزة. بوفر هذا التنسيق عرضاً مرئياً 
عن حالة المشروع. 
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حتى لو لم يكن العديد من فرق التطرير بمتهجية ۴× يستخدمون الأدوات 
البرمجيةء إلا أن بعضها مفيد. منها ما هو تطبيقات معيارية غير مصممة لدعم 
۴× وهناك تطبيقات مصممة لغرض بعينه تم تطويرها خصيصاً لدعمها. 

من بين الأدوات ذات الأغراض العامة ما يأتي : 

# أدوات النمذجة بلغة النمذجة الموحدة :0M1‏ تستخدم هذه الأدوات 
بطریقتین : 

2. إعادة تصميم الشيفرة البرمجية لإنشاء التوثيق. 

آدوات التفاوض حول المتطلبات: يساعد هذا النوع من الأدوات 
المطرّرين والعملاء على تحديد المتطلبات وتحديد آولوياتها وإدارتها فى بيئات 
مختلفة. 

# أدوات الرسائل الفورية: هذه الأدوات مفيدة للبقاء على تواصل مع 
العميل عتدما لا يكون متواجداً في الموقع لمناقشة المتطلبات أو تبادل 
المعلومات بين المبرمجين عندما لا يستطيعوك الجلوس حول مکتب واحد. 

# نظم التحكم بالإصدارات: تساعد هذه الأدوات المطورين على تتبع 
التغيير في الشيفرة البرمجية واستعادة إصدار قابل للتشغيل من الشيفرة البرمجية 
في حال لم تعمل التعديلات بالشكل المطلوب. 

# أدوات الاختبار المؤتمت: إن اختبار الشيفرة البرمجية باستمرار هو أحد 
المظاهر الرئيسة فى منهجية ۴×. إن تنفيذ اختبار التكامل واختبار الشيفرة 
البرمجية بصورة متكررة مر في غاية الأهمية لتحديد عيوب الشيفرة البرمجية 
ومشکلاتها حالما یتم کتابتها. 

من بين التطبيقات المصممة لغرض معيّن ما يأتي : 

أدوات إدارة المشاريع : تركز هذه الأدوات على ممارسات معيّنة من 


بطريقة إلكترونية » إضافة إلى تنظيم الفترات البرمجية التكرارية وغير ذلك. 
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1 - 6 الاستنتاجات 


المنهجيات السريعة هي تنفيذ المفاهيم الأساسية للإدارة بمنهجية 1٥4١‏ في 
صتاعة البرمجيات. يكون التركيز منصبا على تحسين عمليات التطوير باستمرار 
وتحقيق رضا العملاءء وهذان عنصران أساسيان لنجاح تلك المنهجيات. تتمثل 
هذه المظاهر في جميع الممارسات التي يطبقها المطوّرون يومياً. 

إن هدف المنهجيات السريعة ومنهجية ۴× تحديداً هو تسليم برمجية ذات 
جودة عالية في الوقت المحدد وبحسب الموازنة المالية المرصودة» مع التركيز 
على ما هو قَيّم ومفيد للعميل؛ وإنشاء قنوات تواصل لتبادل الآراء مع العميل؛ 
ودعم التغيير الذي قد يتطلبه. لكن هذه المنهجيات لا تدعي أنها مفيدة لاي نوع 
من آنواع المشاريع البرمجية أو لأي نوع من أنواع التنظيمات. فالمنهجيات 
السريعة شأنها شآن أي تقنيات تطوير آخرى لها جوانب تنفذ بطريقة جيدة 
وجوانب أخرى قد تكون تقنيات أخرى أفضل منها. ومع ذلك» وبما إن هذه 
المنهجيات حديغة العهد فإن تحديد هذه الجوانب ما زال قائماً. 
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موؤلفو ومحررو الكتاب 


لورا ٻ و کي :)Laura Bocchi)‏ باحژثة مشاركة في جامعة ليستير - المملكة 
المتحدة حيث تعمل على مشروع شركة سينسوريا (هندسة برمجيات لحاسبات 
الطبقات الخدمية) . نالت درجة الدكتوراء في علم الحاسبات من جامعة بولونيا - 
إيطالياء حيث كانت أبحاثها لنيل هذه الدرجة العلمية متعلقة بالنماذج الرسمية 
التي توزع خدمات الشبكةء وركزت أيضاً على الإجراءات طويلة الأمدء وعلى 
بروتكولات التفاوض أيضاً. 

جان بوثش (ط#ه31«8): يعمل حالياً كنائب رئيس للعملية الهندسية في 
شركة إنتويت. تولى منصب رئيس مختبرات تكنولوجيا البرمجيات والتطبيقات 
في مركز أبحاث شركة نوكيا في فنلندا. وقبل التحاقه بشركة نوكياء ترأس 
مجموعة بحوث هندسة البرمجيات في جامعة جرونينين في هولنداء التي يتولى 
فيها منصب أستاذ في هندسة البرمجيات. نال درجة ماجستير في العلوم من 
جامعة توينتى فى هولندا ودرجة الدكتوراه من جامعة لوند فى السويد. تتضمن 
أنشطة أبحاثه التصميم المعماري للبرمجيات وعائلات متتجات البرمجيات» 
إضافة إلى إدارة البرمجة القائمة على المكونات. 

وهو مؤلف كتاب اتصميم واستخدام معمارية البرمجيات: تبي وتطوير 
طريقة خط إنتاجي» وحرّر عدة كتب ومجلدات أخرى» وألف عدداً مهما من 
المقالات البحثية. كان رئيس تحرير لمجلة تختص بقضايا النشر وترأس 
مؤتمرات عدة كرئيس عام ورئيس برنامج. خدم في العديد من لجان البرامج»› 
وونظم الكثير من ورش العمل. 
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ٻيرند برجيه Bernd Brûgge)‏ : ستاذ في علم الحاسبات ورئيس اللجنة 
التقنية لهندسة البرمجيات التطبيقية في جامعة ميونيخ في ألمانياء وأستاذ مساعد 
في علم الحاسبات في جامعة كارنيجي ميلون في بيتسبرج - بنسلفينيا. نال درچة 
الماجستير عام 1982 والدكتوراه في 1985 من كارنيجي ميلون؛ وحصل على 
الدبلوم في 1987 من جامعة هامبورغ. حصل غلى جائزة هربرت سيمون للتفوق 
في التعليم لعلم الحاسبات في عام 1995. شارك الأستاذ برجيه في تآليف كتاب 
هندسة البرمجياث كائنية التوجه بلغة النمذجة الموحدة 01 وأنماط التصميم 
ولغة الجافا. تتضمن اهتمامات أبحاثه تطوير البرمجيات الموزعة وهندسة 
المتطلبات ومعماريات البرمجيات للانظمة التكيفية وعمليات تطوير البرمجيات 
الذكية» بالإضافة إلى تعليم هندسة البرمجيات القائمة على المشكلات. 


باولو تشانکاریٹي (iصCincari‏ 0ا۴): أستاذ في علم الحاسبات في جامعة 
بولونيا في إيطالياء حيث يقوم بالتدريس ويجري أبحاثاً في مواضيع هندسة 
البرمجيات. نال درجة الدكتوراه في علم الحاسبات من جامعة بيزا عام 1988. 
وهو عضو في جمعية مهندسي الكهرباء والإلکترونیات 18۴۴ الجمعية العالمية 
في الحوسبة الآلية ۸٥0‏ و۸104 ومنظمة ألعاب الكمبيوتر الدولية 1٥6۸‏ 
والمجموعة الخاصة للحوسبة الترفيهية 8616 1۴1۴ التي تتمتع باهتمامات تتضمن 
نماذج التنسيق ولغات البرمجة أدواتية التوجه وأنظمة إدارة الوثائق التي تعمل من 
خلال الويب والبيثات والطرق والأدوات الخاصة بهندسة البرمجيات. وهو 
باحث زائر في جامعة ييل. قام بكتابة أكثر من 40 ورقة بحث نشرت في 
مجلات عالمية» وأكثر من 100 ورقة بحث نشرت في محاضر مؤتمرات عالمية. 

أندريا دي لوشيا (iaءں[ ٥#‏ وeإف4n):‏ حاصل على درجة اللوريا (درجة 
جامعية أولى) في علم الحاسبات من جامعة ساليرنو في إيطاليا في 1991 ودرجة 
الماجستير في علم الحاسبات من جامعة درام في بريطانيا في عام 1996ء 
ودرجة الدكتوراه في الهندسة الإلكترونية وعلم الحاسبات من جامعة نابولي 
«فريديريكو ۲11 في عام ۰1996 وكان عضواً في إدارة كلية في قسم الهندسة في 
جامعة سانيو في إيطاليا في الفترة بين عامي 1996 و2003. تولى آيضاً قيادة 
الأبحاث فى مركز أبحاث تكنولوجيا البرمجيات فى الفترة ما بين عامى 2001 
و2003 . يعمل حالياً کأستاذ دائم في هندسة البرمجيات في قسم الرياضيات 
وعلم الحاسبات في جامعة ساليرنو في إيطالياء ورئيس مختبر هندسة البرمجيات 
ومدير للمدرسة الصيفية العالمية لهندسة البرمجيات. تتضمن أبحاثه الاهتمامات 


398 


الآثية : صيانة البرمجيات والهندسة العكسية وإعادة التصميم وهندسة البرمجيات 
العالمية وإدارة مسار العمل وإدارة التركيب وإدارة الوثائق وإدارة تدفق العمل 
وهندسة الويب واللغات المرئية والتعليم الإلكتروني. نشر الأستاذ دي لوشيا أكثر 
من 100 ورقة بحث عن هله المراضيع في مجلات عالمية» وكتب كتبا 
وملحقات مؤتمرات. قام بتحرير كتب عالمية ومقالات خاصة في مجلات 
عالميةء ويساعد على تنظيم برامج اللجان لعديد من المؤتمرات العالمية في 
حقل هندسة البرمجيات. 

مایکل فیشر :)M ٤طو ۴5‌1٥۲(‏ حصل على الدکتوراه في علم الحاسبات 
من جامعة فيينا للتكنولوجيا في النمسا عام 2007» وقد ساهم في العديد من 
مشاريع البرمجيات منذ عام 1985» عمل كباحث في بداية عام 2002 لمشاريع 
البحوث الأوروبية مُركّزاً على تحليل تطور البرمجيات لعائلات البرامج. التحق 
بمجموعة الأستاذ جال في جامعة زيوريخ في سويسرا عام 2005. في عام 2006 
استلم منصب مهندس برمجيات في قسم علم الزلازل التابع للمؤسسة الفيدرالية 
السويسرية للتكنولوجيا في زيوريخ. ويساهم في مشاريع كالتحليل الزلزالي كجزء 
من مشروع N۸1۴8‏ الأوروبي والمتمشل في نظام الإنذار المبكر للزلازل أو 
نظام إنذار. تتناول آبحائه الاهتمامات التالية: تطور البرمجيات واستعادة هيكلية 
البرنامج والهيكلية المحكومة بالنموذج. 


فیلومینا قیروتټشي )Filomena Ferrucci)‏ : تعمل كأستاذ مشارك في علم 
الحاسبات في جامعة ساليرنو في إيطاليا» حيث تقوم بتدريس محاضرات في 
هندسة البرمجيات وأنظمة معلومات الشبكات. وتولْت منصب مساعد رئيس 
برنامج في المتمر العالمي لهندسة البرمجيات وهندسة المعرفة الرابع عشرء 
وهي محررة ضيفة لموضوع مميز في المجلة العالمية لهندسة البرمجيات 
وهندسة المعرفة الذي تم اختياره كواحد من أفضل الأوراق العلمية التي قدمت 
في المؤتمر. خدمت كمساعدة رئيس برنامج للدورات التعليمية الثانية والثالثة 
والرابعة في المدرسة الصيفية العالمية لهندسة البرمجيات. وكانت عضوة لجلة 
برنامج لعدة مؤتمرات عالمية. تنصب اهتماماتها الرئيسة في أبحاثها على : 
مصفوفات البرمجيات لتقدير جهد البرمجة كائنية التوجه وتطبيقات الشبكة 
وبيئات تطوير البرمجيات واللغات المرئية والتفاعل بين الإنسان والكمبيوتر 
والتعليم الإلكتروئي. ألفت بالتشارك أكثر من 100 ورقة بحثية نشرت في مجلات 
عالمية وكتب وملحقات مؤتمرات عالمية. 
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هارالد غال (ااھG‏ 18ھrوH):‏ آستاذ في هندسة البرمجيات في قسم 
المعلوماتية في جامعة زيوريخ في سويسرا. عمل كأستاذ مشارك في الجامعة 
التقنية في فيينا في مجموعة الأنظمة الموزعة» وحصل من الجامعة نقسها 
على درجة الدكتوراه والماجستير في المعلوماتية. يهتم في بحوثه بهندسة 
البرمجيات بالتركيز على تطور البرمجيات وهيكلية البرمجيات وعمليات هندسة 
البرمجيات الموزعة والمتحركة. تولى منصب رئيس برنامج مؤتمر هندسة 
البرمجيات الأوروبي» وندوة الجمعية العالمية في الحوسبة الآلية (المجموعة 
المختصة المهتمة بهندسة البرمجيات) 2005ء وورشة العمل العالمية حول فهم 
البرمجيات عام 5 وورشة العمل العالمية عن تطور مبادىء البرمجيات 
04 , 


کارلو غينسي (ف#ع#طG‏ ماعه۳): أستاذ ورئيس هندسة البرمجيات في قسم 
الإلكترونيات والمعلوماتية في جامعة البوليتيكنيك في ميلانو في إيطاليا حيث إنه 
مفوض أيضاً من رئيس البحوث فيها. وهو زميل جمعية مهندسي الكهرباء 
والإلکترونیات 18٤۴‏ الجمعية العالمية فى الحوسبة الآلية ٥4ء‏ وهو حائز 
على جائزة الخدمة المميزة للجمعية العالمية فى الحوسبة الاآلية (المجموعة 
المختصة المهتمة بهندسة البرمجيات) لعام 2006. خدم كرئيس عام ورئيس 
برنامج لعدة مؤتمرات مثل المؤتمر العالمي لهندسة البرمجيات» والمؤتمر 
الأوروبى لهندسة البرمجيات. عمل في الفترة بين عامى 2000 و2005 كرئيس 
تحرير لاجراءات ومنهجية هندسة البرمجيات للجمعية العالمية فى الحوسبة الآلية 
.۵M‏ تتمركز اهتمامات أبحاث غيتسى على هندسة البرمجيات ولغات 
البرمجة. وهو مهتم حالياً في المواضيع النظرية والمنهجية والتكنولوجية المتعلقة 
بتطوير تطبيقات شبكة انترنت عريضة. وقام بنشر أكثر من 150 ورقة بحثية 
وثمانية كتب. 


مهدي جزائري (٭روهل افطM):‏ عميد مؤسس لكلية المعلوماتيةء 
وأستاذ في علم الحاسبات في جامعة لوجانو في سويسرا. ويتولى أيضاً منصب 
رئيس النظم الموزعة في الجامعة التقنية في فيينا. أمضى سنوات عديدة في 
البحث والتطوير المتعلق بالبرمجيات في عدة شركات في وادي السيليكون» من 
ضمنها عشر سنوات في مختبرات هوليت باكرد في بالو ألتو في كاليفورنيا. ركز 
في أعماله الأخيرة على هندسة البرمجيات المبئية على مكونات النظم الموزعة»› 
وبالأخص النظم المعتمدة على شبكة الإنترنت. وهو مساعد مؤلف لمفاهيم 
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لغات البرمجة وأساسيات هندسة البرمجيات وهيكلية البرمجة لعائلات 
المنتجات. وهو رفيق جمعية مهندسي الكهرباء والإلکترونیات 1۴۴۴ وعضو في 
جمعية الكمبيوتر السويسرية والألمانية والنمساوية التابعة للجمعية العالمية في 
الحوسبة الآلية. ٠‏ 
لپوناردو مارياني :)[e0nardo Mariani)‏ باحث في جامعة ميلانو في 
إيطاليا. ينصب اهتمامه على هندسة البرمجيات. وبالأخص تحليل واختبار 
البرامج. قبل التحاقه بقسم المعلوماتية والأنظمة والاتصالات» كان الدكتور 
مارياني عالماً ضيفاً في جامعة بيدابورن. يحمل درجة اللوريا من جامعة كامرينو 
والدكتوراه من جامعة ميلانو» وهو عضو في جمعية مهندسي الكهرباء 
والإلكتروتيات» وفي 15٤٤‏ الجمعية العالمية في الحوسبة الآلية ۸°1۷ . 


سيدريك مسنیج :)e rie Mesnage)‏ حصل على درجة الماجستير في 
غلم الحاسبات من جامعة كان في فرنسا حيث اختص بالخوارزميات ونمذجة 
المعلومات. تناولت رسالة الدبلوما خاصته موضوع تصور معطيات تطور 
البرمجيات. وهو حاليا طالب دکتوراه في علم الحاسبات في جامعة لوغانو 
بإشراف الدكتور مهدي جزائري. ويعمل لحساب مشرgۃ Nepomuk‏ الأوروبي 
حيث يركز على هيكليات سطح المكتب الدلالي الاجتماعي. تنصب اهتماماته 
على تطور برمجيات الويب والويب الدلالي والسمات التعاونية والشبكات 
الاجتماعية والعلاقات ما بين علم الحاسبات والعلوم الاجتماعية. 


کارلو مونتانغيرو (0 ١٤۸٣8٠۳‏ و1ءه)٣):‏ أستاذ في المعلوماتية في جامعة 
بيزا في إيطاليا حيث يدرس هندسة البرمجيات في قسم المعلوماتية. ساهم في 
أنشطة القسم كرئيس ونائب رئيس للمنهاج الدراسي لعلم الحاسبات. أمضى 
بضع سنوات في زيارة مراكز الأبحاث في العديد من الدول بما فيها جامعة 
ستاتفور في بالو ألتو في كاليفورنيا وجامعة سيتي في لندن. وتنصب اهتماماته 
في أبحاثه على لغات البرمجة ونمذجة تطوير البرمجيات والطرق الصورية في 
هندسة البرمجيات. حالياًء يركز على النمذجة والتحقق من معالجة الأعمال في 
سياق الهيكليات خدمية التوجه وتحولات نماذج لغة النمذجة الموحدة 1اا 
لمساعدة التحقق من الهيكليات خدمية التوجه بطريقة سهلة الاستعمال. 


روکو موریتې (Rocco Moretti}‏ : حصل على درجة الدكتوراه في علم 
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الحاسبات من جامعة بولونيا في إيطاليا. يعمل حالياً كباحث مشارك في مجال 
هندسة البرمجيات والهيكليات خدمية التوجه في قسم علم الحاسبات في جامعة 
بولونيا. 


فیلیبو باتشیفیتشي (نعااذء۴۵ هممناا۴): حصل على درجة البكالوريوس 
العلمية والماجستير في هندسة الحاسبات من جامعة البوليتيكنيك في ميلانو 
عامي 2003 و2005 على التوالي ودرجة ماجستير في علم الحاسبات من جامعة 
الينوي في شيكاغو في عام 2006. وهو حالياً طالب دكتوراه في قسم 
الإلكترونيات والمعلومات فى جامعة البوليتيكنيك فى ميلانو حاليا. وتتضمن 
أبحاثه الاهتمامات الآتية : تطبيق منهجية هندسة البرمجيات لتطوير نظم حوسبة 
الهواتف الخلوية والمتصلة بالشبكات. وهو أيضاً عضو طالب في جمعية 
مهندسي الکهرباء والإلکترونیات ٠ .1٤۴۴‏ 


ماورو بتسي Mauro Peze)‏ : أستاذ متخصص في هندسة البرمجيات في 
جامعة ميلانو في إيطاليا وأستاذ زائر في جامعة لوغانو في إيطاليا. مهتم بهندسة 
البرمجيات وبالذات اختبار وتحليل البرمجيات. وقبل التحاقه في قسم 
المعلوماتية والأنظمة والاتصالات في جامعة میلانو بیکوکا» عمل کأستاذ مشارك 
في جامعة البوليتيكنك في ميلانوء وعالم زائر في جامعة كاليفورنيا - إرفين وفي 
جامعة ادينبرا. يحمل بتسي درجة اللوريا من جامعة بيزا ودرجة الدكتوراء من 
جامعة ميلانو للبوليتيكنيك. وهو عضو في الجمعية العالمية في الحوسبة الالية 
رفي جمعية مهندسي الكهرباء والإلکترونیات 1۴۴۴ء حيث كان رئيساً 
للجنة الفثية المختصة بتعقيد الحوسبة )۲٥٥×(‏ , 


مارتن بٹزغیر (#۲ع ٣ذ۴‏ صا و) : باحث مشارك رئيس في مجموعة هندسة 
البرمجيات قسم المعلوماتية في جامعة زيوريخ. حصل على درجة الدكتوراه في 
علم الحاسبات من جامعة فيينا للتكنولوجيا في النمسا عام 2005. تنصب 
اهتماماته في أبحاثه على هندسة البرمجيات بالتركيز على تحليل تطور البرامج 
وتصميم البرامج وتحليل الجودة. 

کریستیان بریهوفر ۴٣٥٣ ٥٤٤١(‏ صھناما۳طا٤):‏ قائد فریق آبحاث فی مرکز نوکیا 
للأبحاث. يركز في أبحائثه على الاهتمامات الآتية: الأنظمة الذاتية التنظيم 
والأنظمة كلية الوجودء بالإضافة إلى هيكلية البرمجية وتكنولوجيا البرمجيات 


402 


اتصالات الهاتف الخلوي قبل التحاقه بنوكياء وحصل على درجة الدكتوراه 
وتأهل لتدريس علم الحاسبات في جامعة ميونيخ التقنية في عامي 1995 و2003 
على التوالي. قام بتأليف أكثر من 80 ملشورة وصاحب منح 12 براءة اختراع. له 
دور في عدة لجان برامج لمؤتمرات عن تكنولوجيا الشبكات والبرمجيات. 

فالنتينا بريسوقي :)¥alentina Presutti)‏ باحثة مشاركة في مختبر علم 
توصيف المصطلحات (الإنتولوجى) فى المجلس الوطنى للأبحاث فى روما. 
ونالت درجة الدكتوراه في علم الحاسبات من جامعة بولونيا في إيطاليا. تركز 
في بحوثها العلمية على تكنولوجيا الشبكات الدلالية وهندسة البرمجيات 
وتطبيقات تطوير النماذج للشبكة الدلالية وهندسة الانتولوجيا. 


جيفري روز ۴٥5(‏ رهه 3): درس علم الحاسبات في جامعة كولورادو 
في بولدوير قبل انتقاله إلى سويسرا لإكمال درجة الدكتوراه في جامعة لوجانو. 
وهو مهتم بديمقراطية المعلومات والتطور المستمر لاونعرنت. پبحٹ حالاً في 
مجال صنع شبكات نظير - نظير الذكية التي تبني التواصل بين الناس 
والمعلومات. 


البرتو سيليتي (ا٤:11ا8‏ ١٤#۴طا4):‏ مساعد أستاذ في الجامعة الحرة في 
بولوزانو بوزين في إيطاليا. وحصل على الدكتوراه في هندسة الكمبيوتر وهندسة 
الكهرباء من جامعة جانوا في إيطاليا في عام 2005 وهو مهندس محتثرف. يركز 
في أبحاثه على : هندسة البرمجيات وهندسة البرمجيات المبنية على المكونات 
ودمج وقياس خدمات الشبكات» وأيضاً منهجيات التطوير السريعة والبرمجة 
ذات المصادر المفتوحة. ويعمل في عدة مشاريع ممولة من إيطاليا والاتحاد 
الأوروبي في هذه المجالات. 


هاري سید :)8٣y ۷. 5٬٥٤3(‏ حصل على درجة الماجستير في علم 
المعلومات من جامعة ميريلاند في عام 1969. يحتل مكانة مهمة كأحد قادة 
خبراء التكنولوجيا والأدوات. وهو متخصص في مساندة الشركات على تطوير 
برمجياتها إلى مرحلة متقدمة في التكنولوجيا. يعمل حالياً في شركة مو٣‏ 
nut GmbH‏ فی آلمانیا كرئيس تقنى لخدمات هندسة البرمجيات. مساهماته 
عديدة في مجالات هندسة البرمجيات الرئيسة كالصيانة والمصفوفات وإعادة 
التصميم وفهم البرامج وتطوير الويب» وقد خدم كرئيس عام ورئيس برنامج 
وعضو لجنة تسيير وعضو لجنة برنامج لمؤتمرات مهمة في هذه المجالات. 
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ألف 15 كتاباًء وأكثر من 160 مقالة تقنية. طور بنفسه أكثر من 60 أداة برمجة› 
وتولی دوراً في آکثر من 40 مشرو برمجيات. ويدڙس الآن في ست جامعات 
هي باسو وريغنسبورغ وكوبلينز في آلمانيا وبودابست وسيغد في هنغاريا 
وبينيفينتو في إيطاليا. 

جانكارلو سوتشي (اءعس8 ماعوءمها6) : أستاذ في الجامعة الحرة في بولزانو 
بوزين في إيطاليا» حيث يدير مركز هندسة البرمجيات التطبيقية. تولى عدة 
مناصب سابقاًء منها: أستاذ في جامعة البيرتا في مدينة ادمينتون في كنداء 
وأستاذ مشارك في جامعة كالغاري في البيرتاء ومساعد أستاذ في جامعة ترينتو 
في إيطاليا. حاصل على منحة فولبرايت التعليمية. تتضمن اهتماماته في أبحاثه 
عدة مجالات في هندسة البرمجيات بما في ذلك البرمجة مفتوحة المصدر 
والمنهجيات الذكية وهندسة البرمجيات التجريبية وهندسة البرمجيات خلال 
الإنترنت وخطوط منتجات البرمجيات وإعادة استخدام البرامج. كتب أكثر من 
0 ورقة بحثية نشرت في مجلات عالمية والكتب والمۇتمرات» وقد حرّر 
أربعة كتب. كان رئيساً ورئیساً مساعداً لحدة مؤتمرات وورش عمل عالميةء وهو 
رئيس شبكات بحثية عالمية. الأستاذ سوتشي مستشار لعدة مؤسسات خاصة 
وحكومية في مختلف انحاء العالم. 


جيني تورتورا :)Genny Tortora)‏ أستاذْة منڈ عام 0 في جامعة ساليرنو 
في إيطاليا حيث تدرّس نظم قواعد البيانات ومبادىء علم الحاسبات. كانت في 
عام 1998 عضرا مؤسساً لقسم الرياضيات وعلم الحاسبات» وعملت كرئيسة 
للقسم حتى تشرين الثاني/ نوفمبر عام 2000 حين تولّت عمادة كلية علوم 
الرياضيات والفيزياء والطبيعة. تتناول أبحائثها الاهتمامات الآتية: بيثات تطوير 
البرمجيات واللغات المرئية ونظم المعلومات الجغرافية ونظم المعلومات 
التصويرية. مؤلفة ومساعدة مؤلف لعدة آوراق بحثية نشرت في مجلات علمية 
وكتب وملحقات لمؤتمرات تحكيميةء وهي أيضاً محررة مساعدة لكتابين. 
عملت كرئيسة برنامج وعضوة لجنة برنامج لعدد من المؤتمرات العالمية. كانت 
عضو لجنة توجيهية في ندوة لغات وبيئات الحوسبة القائمة على العامل البشري 
والبشرية التابعة لجمعية مهندسي الكهرباء والإلکترونیات 1٤٤۴‏ منذ عام 1999 
حتى عام 2003. وهي أيضاً عضو متميّز في جمعية الحاسوب التابعة لجمعية 
مهندسي الكهرباء والإلكترونيات. 
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ماوريتشو توتشي (iء٥ں1‏ منعiسو1):‏ حصل على درجة اللوريا في علم 
الحاسبات من جامعة ساليرنو في إيطاليا عام 1988» ومذاك وهو يعمل كأستاذ 
في علم الحاسبات في جامعة ساليرنو حيث يقوم بتدريس دورات برمجة لطلاب 
البكالوريوس ودورات تصميم النظم التفاعلية للخريجين. تنصب اهتماماته في 
بحوثه على النماذج الرسمية وتقنيات تصميم وتطبيق البيئات المرئية وتقنيات 
التبويب المبنية على المحتوى لاستراجع قائمة بيانات الصور وعلى آدوات 
هندسة البرمجيات. 


جیلیس فان غارب (وعس ص 1#اة3): مهندس أبحاث في مركز آبحاث 
نوكيا في هلسينكي في فنلندا» حيث تم ضمه للعمل في مشاريع آبحاث متعلقة 
بخدمات والبحث في الهاتف الخلوي»ء ويعمل حاليا على مبادىء متعلقة 
بتطبيقات المساحات الذكية. تتضمن اهتمامات أبحاثه أطر العمل كائنية التوجه 
وخطوط إنتاج البرمجيات وإدارة تغير البرمجيات تأكل تصاميم البرمجيات 
والحوسبة كلية الوجود. وحصل على درجة الدكتوراه من جامعة غرونيغن في 
هولندا عام 2003, قام بنشر عدد كبير من المقالات المتعلقة بالموضيع السابقة 
الذكر. في عام 2005 وقبل التحاقه بنوكيا» عمل كمدير إطلاق برامج في ×6 
tive Online Development‏ وهي شركة مزودة رائدة في هولندا لأنظمة إدارة 
المحتوى» وعمل أيضاً كباحث في جامعة غرونيغن في معهد بلياكينيا 
للتكنولوجيا في السويد. 


جويسپي فپساجيو Giuseppe Visaggio)‏ ): أستاذ في هندسة البرمجيات في 
قسم المعلوماتية في جامعة باري في إيطاليا. تغطي اهتماماته العلمية الحالية 
عددا من مجالات هندسة البرمجيات وهيى: جودة البرمجيات وهندسة 
البرمجيات التجريبية وإنتاج وصيانة البرمجيات القائم على خطوط الإنتاج 
وخدمات المحتوى والويب وإدارة المعرفة ومعمل الخبرة. نشر في هذه 
المجالات كتباً ومقالات في مجلات عالميةء وقذم أوراقاً علمية في عدد من 
المۋتمرات. وهو عضو في عدة لجان برامج مؤتمرات عالمية ومراجع لعدة 
مجلات علمية مختصة في هندسة البرمجيات في مجال الهندسة العكسية 
وفهم البرمجيات وصيانتها وهندسة البرمجيات. كان عضواً في اللجنة 
التوجيهية للمؤتثمر العالمي لصيانة البرمجيات حتی عام 3. یپتولی 
البروفيسور دور فى اللجنة التوجيهية للاتحاد العالمى لصئاعة اللاسلكى 1۷۶٥١‏ 
والمۋتمر الأوروبي لصيانة وإعادة هندسة البرمجيات CSMR‏ ومرکز آبحاث 
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تکنولوجيا البرمجيات ۸۳081 . > وهو أيضاً عضو في شبكة أبحاث هندسة 
البر مجيات العالمية (15SERN)‏ التي تت تتضمن العديد من الجامعات والصناعات في 
كافة أنحاء العالم. 


تيمو وولف (Timo WolD‏ ; هو مساعد بحوث في الجامعة التفنية في 
على درجة الدكتوراء حيث يط بحن المواضيم الآتية: هندسة المتطلبات 
والتصميم كائني التوجه ودعم الأدوات والتطوير الموزع في عدة مواقع. 
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ثبت المختصرات 


هندسة البرمجيات ذات التو جه الأدواي 
الهيكلة ذات التوجه الخدماتي 
الهيكلية المعتمدة على النماذج 
هيكلية خدمات الويب 

هيكلية خدمات الشبكية الفتوحة 
هندسة البرمجيات ذات التوجه الخدماقي 
حل المشاكل الموزعة 

بروتوكول الشبكة التعاقدي 
مؤسسة الأدوات المادية الذكية 
الهيكلية المعتمدة على النموذج 
إطار عمل موارد خدمات الويب 
لغة وصف خدمات الويب 

آلة تحديد الحالة المحدودة 

لغة النمذجة الموحدة 

تطوير البرجيات التكيّفية 

البرجة القصوى 

أسلوب تطوير النظم الديناميكية 
كفاءة أهداف الاستثمار 

إدارة المشاريع 

إطار العمل متعدد العروض 
الاستقصاء التجريبي 


Agent-Oriented Software En gineering 
Service-Oriented Architecture 
Model-Driven Architecture 

Web Services Architecture 

Open Grid Service Architecture 
Service-Oriented Software Engineering 
Distributed Problem Solving 

Contract Net Protocol 

Foundation for Intelligent Physical Agents 
MODEL-DRIVEN ARCHITECTURE 
Web Service Resource Framework 

Web Services Description Language 
finite state machine 

Unified Modeling Laiğuage 

Adaptive Software Development 
eXtreme Programming 

Dytarnic Systems Development Method 
Fitness of Investment goals () 

Project Management (PM) 

Multiview Framework (MF) 


empirical investigations = (ET) 
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AOSE 
SOA 
MDA 
WSA 
OGSA 
SOSE 
DPS 
CNP 
FIPA 
MDA 
WSRF 
WSDL 
FSM 
UML 
ASD 
XP 
DSDM 
FI 

PM 
MF 
EI 


مقاييس السؤال المستهدف 
إصلاح سريع 

تحسين تکراري 

الصيانة الاستائية 

الهندسة العكسية 

هيكلية وسيط طلب الكائن الشترك 
مليون سطر من الشيفرة البرجية 
لغة توصيف مصطلحات الويب 
كإطار عمل وصف المصادر 
إطار عملي نمذجة خلمة الويب 
توصيف نمذجة خلمة الويب 
لغة فيود الكائن 

عمليات الاتصال السللة 
خطط تدفق تحكم النوع 
غططات نوع الداخلي حاف 
بروتوكول التطبيقات 

واجهة البوابة المشتركة 

بئمط اتصال إجرائي عن بعد 


تطبيقات النصوص التشعبة الخاصة 


بالویب 
بلغة تنفيذ عمليات الأعمال 
الوصف العام والاكتشاف والتكامل 


لغة تعريف خدمة الويب 
قاعدة بيانات اللإأصدارات السابقة 
العارض المصدري ثلاثي الأبعاد 


Goal Question Metrics 
Quick Fix 

Iterative Enhancements 
Extraordinary Maintenance 
Reverse Engineering 


Common Object Request Broker 
Architecture 


Million Lines of Code 

Web Ontology Language 
Resource Description Framework 
Web service Modeling Framework 
Web service Modeling Ontology 
Object Constraint Language 
communicating sequential processes 
Class Control Flow Graph 

Java Interclass Graphs 

Wireless Application Protocol 
(common gateway interface 


remote procedure call 


Working Group 


Business Process Execution Language 


Universal Description, Discovery and 


Integration (UDDI 
Web Service Definition Language 
release history database 


Source Viewer 3D 


408 


GQM 
QF 

IE 

EM 

RE 
CORBA 


MLOC 
OWL, 
RDF 
WSFM 
WSMO 
OCL 
CSP 
CCFG 
JIGs 
WAP 
CGI 
RPC 


WHATWG Web Hypertext Application Technology 


BPEL 
UDDI 


WSDL. 
RHDB 
SY3D 


ثبت المصطلحات 


نظري (ملخص) 

نوع البيانات الملخص 
ملخصات 

اختبار القبول 

إمكانية الوصول 

العملية » السجل الفعال 
خططات النشاط 

نمط الموائم 

تطوير البرجيات التكيفية 

أداة (أدوات) 

المنهجيات أدواتية التو جه 
هندسة البرجيات أدواتية التو جه 
دورة حياة البرمجيات أدواثية التوجه 


تجميع 
لمنهجيات السريعة 

بيان منهجية التطوير السريع 
منهجيات التطوير السريعة 
النمذجة السريعة 

الخصائص المحبرية 

الفرضية البديلة 

لیل 

الأنشطة التحليلية 


Abstract 

Abstract Data Type 
Abstractions 

Acceptance Test 
Accessability 
Activerecord 

Activity Diagrams 
Adapter Patter 
Adaptive Softwate Development (Asd) 
Agent(S) 

Agent-Oriented Methods 


Agent-Oriented Software Engineering (Aose) 
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Agent-Oriented Software Life Cycle 
Aggregation 

Agile 

Agile Manifesto 

Agile Methods 

Agile Modelling 

Algebraic Specifications 
Alternative Hypothesis 

Analysis 

Analysis Activities 


التلحقق من فاعلية 

تطبيقات 

الشرائح الهيكلية 

هيکلية/ هیکليات 

التقييم والتحسينات 

ارتباط» اتحاد/ اتحادات 
تغطية نباية الارتباط التعددية 
الإنشاء الأوتوماتيكي 

ربط 

نظم التدوين 

تغطية -حلقة الحدود الداخلية 
وسیط 

التصفح 

تغبير في الأعمال 

لغة تنفيذ عمليات الأعمال 
أدوات هندسة البرمجيات بمساعدة الحاسوب 
بٽاء» موجه 


واجهة البوابة المشتركة 


تغطية خاصية النرع 
غطط تدفق التحكم بالنوع 
غخططات النوع أو الصثف 

نوع/ أنواع» صتف/ أصناف 
خادم = تابع 

°0°0M0 نموذج‎ 

الا-ختبار المحدد بالشيفرة البرجية 
خططات التشارك 

تعاوني 

نظام العلامات التشاركية 


And Validation 

Applications 

Architecture Slices 
Architecture ($) 

Assessment And Improvements 
Agsociation 

Association-End Multiplicity Coverage 
Automatic Generation Of 

Binding 

Blog Systems 

Boundary Interior Loop Coverage 
Broker 

Browser 

Buginess Change 

Business Process Execution Language (Bpel) 
CASE Tool(S) 

Cause Construct 

CGI (Common Gateway Interface) 
Change Coupling 

Choreographed 

Choreography. 

Class Attribute Coverage 

Class Conttol Flow Graph (Ccfg) 
Class Diagtams 

Class(Es) 

Client-Server 

COCOMO Model 

Code-Based 

Collaboration Diagrams 
Collaborative 


Collaborative Tagging Systems 
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تغطية التحصيل 

القواسم المشتركة 

عمليات التواصل التعاقبة 
الترافقية 

عنصر/ عناصر 

التركيب/ البنية 

منهجية عائلة المنتج الت ركيبية 


تغطية الحالة 

حدس 

ناء / بنية 

المستهلك 

إدراك حسب السياق 

بروتوكول الشبكة التعاقدي °۸۲ 


تنسیق 
هيكاية وسيط طلب الكائن ا لمشترك 
البر تجيات الحاهزة التجارية 

التقارن 

معايير التغطية (الشمول) 

معاییر 
العائلة الكريستالية 

نظام الإصدارات التزامنة 
العده السيكلوماق 


بصم م 
تصميم فابل ومعد للتغيير 
أنماط التصميم 


Collection Coverage 
Commoiality 
Commuticating Sequential Processes (Cap) 
Compatibility 
Component(§) 
Composition(S) 
Compositional Product Family Approach 
Compound 
Conclusion 
Concurrency 
Condition Coverage 
Conjecture 

Construct 

Consumer 
Context-Aware 
Contract Net Protocol (Cnp) 
Coordination 
Coordination Relation 
Corba 

Cots 

Coupling 

Coverage Criteria 
Criteria 

Crystal Family 

Cvs 

Cyclomatic Num ber 
Data Flow (DF) 
Deployment 

Design 

Design For Change 
Design Pattern(S) 
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المحول 

حل المشكلة الموزعة المواقع 
النظم الموزعة المواقع (المنتشرة) 
منهجية فرق تسدا 

إطار العمل ٥عدوزط‏ 

بنایکي 


منهجية تطرير النظم الديناميكية 


نوع دینامیکي 

تغطية كل رسالة في الرابط 
الأعمال الالكترونية 
نظام Eclipse‏ 

بثاء التأثير 
الاستقصاء التجريبي 
إخفاء التفاصيل 
التحكم الذاقي 
سيناريوهاٿ متماثلة 
العلوم الإلكتروية 
حدث/ اآحداث 


تطور الت ر کیب 


تطوري 

مظاهر التطور 

معالج الحالات الاستفنائية 
حالات استفنائية 
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Design Time 

Developer Contribution 
Development 

Diagrammatic Specifications 
Discovery 

Dispatcher 


Distributed Problem Solving (Dps) 


Distributed Systems 


Divide-And-Conquer Approach 


Django 
Dynamic 


Dynanic Systems Development Method 


(Dsdm) 
Dynamic Type 


Each Message On Link Coverage 


E-Business 

Eclipse 

Effect Construct 
Empirical Investigation(S) 
Encapsulation 
Encapsulation Of 
Endogenous Control 
Equivalent Scenarios 
E-Sciençe 

Event(S) 

Evolution Of Composition 
Evolution 

Evolutionary 
Evolutionary Aspects 
Exception Handler(S) 
Exception(S) 


سيطرة خارجية 

مصنع التجربة 

تجربة / تجربة متحكم بها 
الأفراد التجريبيين (المتطوعون) 
استقصاء استكشافي 

خارجي 

البرجة القصوى (۲>) 

خطا (عیب) 

تطور الميزات 

نہائي 

آلة الحالة المنتهية 

الجدار الثاري 

مواصفات نظامية 

مۇسسة الأدواث المادية الذكية (۴۲۴۸) 


الکسيري 

إطار عمل / أطر عمل 
تغطية المسند التام 
منهجية هن6 

تغطية التميم 

معيار التعميم 

عام/ شامل 

حیز تنسیتق شامل 

(GTA) lÎ 

مقاييس السؤال المستهدف 
وأجهة رسومية 
الشبكة» نقش 

أدوات الشبكة 

خدمات الشبكة 
هيكلية -خدمات الشبكة 


واجهة الاستخدام التصورية 


Exogenous Control 

Experience Factory (Ef 
Experiment/Controlled Experiment 
Experimental Subjects 
Explorative Investigation 
External 

Extreme Programming (XP) 
Fault(S) 

Feature Evolution 

Final 

Finite State Machine(S) (Fsms) 
Firewalls 

Formal Specifications 


Foutıdation For Intelligent Physical Agents 
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(FIPA) 

Fractal 

Framework (8S) 

Full Predicate Coverage 

Gaia 

Generalization Coverage 
Generalization Criterion 
Generic 

Global Coordination Space (Ocs) 
Globus Toolkit 4 (Gt4) 

Goal Question Metrics (GOqm) 
Graphical 

Grid 

Grid Agents 

Grid Services 

Grid Services Architecture (Ga) 
Gui 


حتوى )وا1 الذكي 

Halstead qz‏ الذهني 

صعوبة بر نامج (Halstead)‏ 

حدس مهني 

التسلسل الهرمي 

لغْة ترميز النصوص التشعبية 

بروتوكول نقل النصوص التشعبية المحمي 


فر صيه 


.# 


معرف 

معرّف المصادر الرحد 0۸1 ) 
معايير معهد مهندسي الكهرباء وال لكترونيات 
في بيئة المختبر 

في بيئة حيوية 

إخفاء المعلومات 

التوارث 

اعتمادية ناشثة عن التوارث 
بداتي 

التهيئة 

تکامل 

المنهجية مركزية التكامل 
منهجية معتمدة على التكامل 
اختبار النوع البيني 

واجهة بينية 

داخل 

التوافقية 

اختبار النوع الداخلي 

ثابت» لا متغير 

استدعاء 


منصة تطوير -خدمات الويب الدلالي IRS-ITI‏ 


Halstead Intelligent Content 
Halstead Mental Effort 
Halstead Program Difficulty 
Heuristic 

Hietatrchy Of 

Html 

Hittps 

Hypertext 

Hypothesis 

Identifier 

Identifier (URT) 

TEEE Standard 
Implementation 

In Vitro 

In Vivo 

Information Hiding 
Inheritance 

Inheritance Dependency 
Initial 

Initialization 

Integration 
Integration-Centric Approach 
Titegrationt-Oriented Approach 
TInterclass 

Interface 

Intermal 

Iiteroperability 

Intraclags 

Invariant 

Invocation 


IRS-II 
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علاقة 15-۸ 

فترة برجية تكرارية 

إطار عمل تطبيقات الويب بلغة ال جافا (12۴۴) 
استدعاء المنهجية عن بعد الخاص ب (ةبةل) 
تقنية شبكة 7۸0) لبناء النظم الموزعة 
خططات (اهاہذ البيائية 

مصادر المعرفة 

لغات 

قانون 

إدارة منهجية 121 

میراث 

خط العمر 

رابط/ روابط 

التحويل إلى المواصفات المحلية للمستخدم 
إدراك حسب الوقع 

قابلية الصيانة 

صيانة 

إدارة 

مقياس مكاب لدرجة تعقد النظام 

مقیاس/ مقاییس 

آلیات 

تغطية مسارات الرسالة 

رسالة/ رسائل 

الاستعارات 

أسلوب/ آسالیپ/ عمليات 

مقياس (معيار الأداء) 
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IS-A Relationship 
Iterative 

J2ee 

Java RMI 

Jini 

Kiviat Diagrams 
Knowledge Sources (Kss) 
Languages 

Law 

Lean Management 
Legacy 

Lifeline 

Link(S) 

Localization Of 
Location-Aware 
Maintainability 
Maintenance 
Management 

Mccabe Cyclomatic Complexity 
Measure(S) 
Mechanisms 

Message Paths Coverage 
Message) 

Metaphors 

Method($) 

Metric($) 

Middleware 

Migration 

Mining 

Model Transformation 


Model View Controller (Mvc) 


نمو ذج/ نمافج 

هيکليات عددة بالنموذج 
النمطية 

وحدة/ وحداتثت 

هيكلياث متعددة الأدوات 
مقاييس التطور المتعددة 
الطبقات المتعددة 

النظم المرتبطة بالشبكة 
الاختبارات غير المعلمية 

فرضية العدم 

لغة قيو د الكائن )0٤1(‏ 
خططات الكائن 

کائن/ کوائن 

المطابقة ذات العلاقات الكائنية 
ملاحظة/ ملاحظات 

نمط المراقب 

واجهة الوحدة أو واجهة الموديول 
واجهة الخدمة 

البرتجيات الجاهزة 

مكونات جاهزة للاستخدام 
علم التوصيف 

هيكلية -خدمات الشبكة المفتوحة 
برجية ذات مصدر مفتوح 
الاستفادة الأمثل من تنفيذ حالة الاختبار 
المشاورات 

متناسق/ متناغم 

تنسيق» مناغمة 

معمارية متفوقة 

إطار العمل 0861 

الاستعانة بمصادر خارجية 


Model(S) 

Model-Driven Atrchiteçtutes 
Modularity 

Module($) 

Multi-Agent Atrçhitectures 
Multiple Evolution Metrics 
Multi-Tier 

Networked Systems 
Nonparametric Tests 

Null Hypothesis 

Object Constraint Language (OCL) 
Object Diagrams 

Object(S) 

Object- Relational Mapping 
Observation(S) 

Observer Pattern 

Of Module 

Of Service 

OfF-The-Shelf 
OfE-The-Shelf Components 
Ontology 


Open Grid Service Architecture (Ogsa) 


Open Soutce Softwate 

Operational Relationship 
Optimization Of Test Case Executiot 
Oracles 

Orchestrated 

Orchestration 


Orchestration-Choreography Languages 


Osgi 


Outsourcing 


معمارية متفوقة 
خخططات الحزمة 
حزمة/ حزم 

البرجة الثنائية 
الاختبارات المعلمية 
ام 

قانون پارناس 
نظرية بارناس 
تغطية المسار 

نظیر - نظير 

لغة البرجة ۲۲1۴ 
منصات البر يات 
تعدد الآشکال 
شرط لاحق 
استقصاء تحليل ما بعد الحدث 
شرط مسبق 

مبداً 

خاص 

حابات العملية 
عملية/ عمليات 
هيكلية خط الإنتاج 
مستوى تعقد البرنامج 
فهم البرنامج 
التحقق من المشروع 
مزود 

عام 

نظم نشر- اشتراك 
نظم نشر- اشتراك 
الحودة 

الاسترجاع 


إعادة التصميم 


Overengineered Architecture 
Package Diagrams 
Package($) 

Pair Programming 
Parametric Tests 

Parent 

Parnas Law 

Parnas Theory 

Path Coverage 
Peer-To-Peer 

Php 

Platform(5) 
Polymorphism 
Post-Condition 
Postmortem Investigation 
Pre-Condition 

Principle 

Private 

Process Calculations (I) 
Process(Es) 

Product Line Architecture 
Program Complexity 
Prtogtarm Understanding 
Project Iuvestigation 
Provider 

Public 

Publish-Su bscri be 
Publish-Subscribe Systems 
Quality 

Recovering 


Reengineering 
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تغيير تصميم البرنامج دون التأثير على النتائج 
هيكليات مر جعية 
الانعكاس 

اختبار الانحدار 
الموثوقية/ الاعتمادية 
تنسیق عن بعد 

أستدعاء إجراء عن بعد 
تكرار التجربة 

متطلبات 

إطار عمل وصف المصادر 
استر جاع 

استقصاء اثر رجعي 
الهندسة العكسية 
المخاطر والتهديدات 
استدعاء المنهجية عن بعد 
بر#جية Ruby‏ 

فترة التنفيذ 

التدرجية 

منهجية ں8 

الأمن 

الشبكة الدلالية 

الويب الدلالي 

-خدمات الويب الدلالي 
فصل الا-ختصاصات 
غططات التتابع 

متعاقپب 

خدمة/ ۔خدمات 

الهيكلية خدمية التو جه 
هيکليات عددة با لخدمات 
البرجة خدمية التوجه 
وسيط خدمي التوجه 


Refactoring 

Referetiçe Architectures 

Reflection 

Regression 

Reliability 

Remote Object Coordination 
Remote Procedure Call (RPC) 
Replication 

Requirements 

Resource Description Framework (Rd) 
Restoration 

Retrospective Investigation 
Reverse Engineering 

Risks And Threats 

Rmi Remote Method Invocation 
Ruby 

Run Time 

Scalability 

Scrum 

Security 

Semantic Grid 

Semantic Web 

Semantic Web Service 

Separation of Concerts 

Sequence Diagrams 

Sequential 

Service(S) 

Service-Oriented Architecture (Soa) 
Service-Oriented Architectures (SOA) 
Service-Oriented Computing 


Service-Oriented Middleware 
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تطوير البرخجيات خلمية التو جه 


بروتوكول وصولية الكائن البسيط 


برجية 

هيكلية البرجية 
مكونات البرجية 
تركيب البرجية 
تاليف البرجية 
عملية تطوير البرجية 
تطور البرخجيات 
عملية برجية 

عائلات اتنج البرجية 


تصور البرجية 


تقنيات قائمة على المواصفات 
مواصفات 

المنهجية الحلزونية 

حالة (-حالات) 

سلوك معتمد على الحالة 
خططات المالة 

سلوك المعتمد على الحالة 
ثابت (مستقر) 

نوع ثابت 

نمط الإستراتيجية 

هیکليء بنیوي 

لخة الاستعلام ا لموحدة 
شيفرة تحويل العوامل 

نوع فرعي (مشتق من رئيسي) 
إشتراك 

نوخ رئيسي 

مسح 


Service-Oriented Software Development 
Simple Object Access Protocol (Soap) 
Software 

Software Atçhitectute 

Software Components 

Software Composition 

Software Costs 

Software Development Process 
Software Evolution 

Software Process 

Software Product Families 
Software Visualization 
Specializations 

Specification. 

Specificatio i-Based Techiiques, 
Specifications 

Spiral 

State(S) 

State-Based Behavior Of 
Statecharts 

State-Dependent Behavior 

Static 

Static Type 

Strategy Pattern 

Structural 

Structured Query Language (SqI) 
Stub(S) 

Subclass 

Subscription 

Superclass 


Survey 
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نظم (آنظمة) 

علامة 

وضع علامات 

المواصفات النطقية المؤفتة 

أنشطة اختبار 

سپناریو اختبار 

جموعات اختبار 

تطوير البرتجيات المحدد بالاختبارات 


انوع 

لغْة الثمذجة الموحدة 

العملية الموحدة 

المورد المو-حد 

الوصف العام والاكتشاف والتكامل (0521) 


دد مواقع المصادر الموحدة 81ل 
قابلية الاستخدام 

سیناریو استخدام 

سجچل مهام الاستخدام 

اعتمادية الاستخدام 

صلا حية 

متغیر / متغيرات 


التحقق من صحة 


Systems 

Tag 

Tagging 

Temporal Logic Specifications 
Test Activities 

Test Case(S) 

Test Suites 

Test-Driven Development 
Testing 

Theory 

Time 

Transition Coverage 
Transition(S) 

Translation Time 

Tropos 

Tuple-Space 

Tuple-Space Systems 

Types 

Unified Modeling Latguage (Uml), 
Unified Process (Up) 

Uniform Resource 

Universal Description, Discovery And 
Integration (UDDI) 

Url 

Usability 

Use Case 

User Stories 

Uses Dependency 

Validity 

Variable(S) 


Verification 


ترقيم الإصدارات 
طريقة عرض 
فابلية الرؤية 


منهجية الشلال 

الويب 

أطر عمل تطبيقات الويب 
تطبيقات الويب 

هندسة الويب 

لغة توصيف الويب 

هيكلية خدمات الويب 

لغة تعريف خدمة الويب 

أطار عمل نمذجة خدمة الويب 
توصيف نمذجة خدماث الويب 
توصيف نمذجة خدمة الويب 
إطار عمل مصدر خدمة الويب 
خدمات الويب 


لغة وصف خدمات الويب 


برتوكول «الضفدع ذو الفم الواسع؛ 


نظم الويكي 

نظام إدارة سير العمل 

منفذ الطي 

الطي 

لغة الترميز القابلة للامتداد 
عملية التطوير بمنهجية ۲× 


Versioning 

View(S) 

Visibility 

Visibility 

Visualization 

Waterfall 

Web 

Web Application Framework(S), 

Web Application(S) 

Web Engineering 

Web Ontology Language (Owl) 

Web Service Architecture (Wsa) 

Web Service Definition Language (WsdI) 
Web Service Modeling Framework (Wsfm) 
Web Service Modeling Ontology (Wsmo) 
Web Service Modeling Ontology (Wsmo) 
Web Service Resource Framework (Wsrf) 
Web Service(S) 

Web Services Description Language (WsdI) 
Wide-Mouthed Frog Protocol 

Wiki Systems 

Workflow Management System (Wfms) 
Wrapper 

Wrapping 

Xml 


XP Development Process 
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فهھرس 


-آ- 


834 : Java Mouse Event Listener آلیات‎ 

آلیات تر کیب الہر یات : 18ء 25 

الأجهزة التابعة: 27ء 117ء 202ء 235 

أجهزة الحاسوب المركزية : 30 

الاختبار الجبري : 154 

اختبار القبول : 386 

الاختبارات غير المعلمية : 324 

الاختباراث المعلمية : 324 

الأخطا: 29ء 32 57-56» 66ء 137» 
145 158-157 160« 166« 179- 
180 188 195-194« 209« 252« 
282-6 309 328 330 336« 
371 374« 378 

إخفاء المعلومات : 33-32 138ء 142» 307 

294 : Bauhaus la! 

294 : Bookshelf êlî! 

295 : CodeCrawler al) 

295 : Creole laî! 

إلأداة الوط : 294 

125 : Globus Tookkit alî! 

2935 : Klashinsky laî! 

294 : Rigi الأداة‎ 

إدارة الحودة: 17-16» 30» 39 46› 57› 
59 61 76-74 80« 137« 171« 


344 342 329 311 245 20 
372 370-369 359-358 52 
402 «390 


إدارة العمليات : 18ء 21ء 301» 372 

الأدوات (واسععA):‏ 90ء 92 119-118 
21 125 129« 131« 258 

آدو ات إدارة المشاريع : 394 

الأدوات البر ية : 19ء 120 129» 394 

آلأدوات ذات الأغراض العامة : 394 

الأدوأت الشبكية: 119ء 125 

ارتباط النْظّم : 68 

ارتباط الوظائف : 131 

الارتباطات : 39 92› 123 › 152› 181› 
234« 281-278 

الاسترجاع: 61» 95ء 102-101» 109 


«358 356-355 269 267 7 
394 «376 

الاستعارة: 295 378› 384 

الاستعانة بمصادر خارجية : 392 

الاستقصاءات التجريبية : 306-304 › 308- 
09 321-320 335-332 337- 
8 344-343 346 348 360- 
361 


أسلوب تطوير النْظّم الديناميكية : 370 
إطار عمل تطبيقات الريب : 208 


إطار عمل وصف الصادر (۸2۴): 129 
222-1 

أطر العمل : 20ء 118 126-125ء 129- 
130 167 174 179« 208-207« 
222-1 311 338 

إعادة الاستخدام: 36 139 236» 241 
245 258 

إعادة التصميم : 261» 295-294 347 
359-7 369› 399 403 

الأاعتمادية: 19ء 37ء 45-44 62-61» 
131 207« 390 

الأعمال الإلكترونية: 119-118ء 122» 195 

أندروز» آنلياس : 152 

أنظمة التدوين : 210› 212 

أنماط التصميم : 19» 84-83ء 112» 120ء 
204« 398 

الأنواع: 27ء 34› 70ء 138 175 256 
261 

أورسوء» أليساندرو: 163 

أوشي» ويليام : 392 

أوفوت» جيف : 152 

ولیفیتو: روو : 22 


إیموپردوف» کلاودیو : ۰149 154 
- ب - 

باتیل» برافینا: 22 

پارناس» دیفید : 32-31» 307 

باريسي» لوتشیانو : 47 

باسیفیکي» فیلیبو : 25 

باسیلي» فیکتو ر: 339-338 

باندي» هیمینت : 159 

ٻاي ۰ يوغو : 163 

البحث التجريبي : 204 » 309 


برايند» ليونيل : 154 

البرحجة الإجرائية: 19ء 138 

البرتجياث أدواتية الت رجه (۸08۴): 19› 
120-17 122 

البرجيات التجارية : 61-60 80 

البرمجيات الخارجة: 80 

البرمجيات خدمية التوجه: 122-121 126 
131 

البرتجيات ذات التو جه التكاملي : 73 

البرتجيات ذات المصادر المتاحة للاستخدام : 
54 

برجيات العام المغتوح : 28 

البر ميات كائنية التوجه: 26ء 140-139 »› 
246 

البر جياتة كائنية التوجه: 140-139 246 

البرامج ذات البنية الموحدة: 30 

295 : Cast پرنامج‎ 

پرنامج : 270» 295 

رتام ھالنMo‏ : 270 272› 275 278- 
280« 284 

بر نامج Sotograph‏ : 295 

72 : Visual Age بر تامج‎ 

برنامج فورتران: 230» 235 

برنامج كوہول: 230 250-247» 253- 
260« 262 

بروتوكول الشبكة التعاقدي :))N۴(‏ 124 

بروتوكول «الضفدع ذو الفم الواسع»: 193 

بروتوكول نقل النصوص التشعبية : 44؛ 
89 93 96 100« 108« 117« 201- 
204 235„ 280« 371 

بروتوكول وصولية الكائن البسيطة (80۸۴) : 
44« 235„ 247 


بروغ؛ بیرند: ۰83 91 98 

بریهوفیر» کریستیان : 51 

بتزغیر» مارتین : 267 

بوتشولتز» مخائیل : 198 

پوتشي» لورا: 117 

بودیه» تشیارا: 198 

ہوش۰ جان : 51 

بيتسي» ماريو : ۰137 163 

بیتشياباء دانييلا: 198 

ٻیرون»› لارا: 198 

بيك» کینت : 22 375 

بینزغر» مارتین : ۰267 ۰270 402 

بینی » باول : 22 

البيثة الحيرية : 309 

بيئة المختبر : 2310 

ت 

التبعيات : 58 62ء 70-68 78-76› 
121 246 269 280„ 317-315 

: (Usage Dependencies) تبعیات الاستخدام‎ 
269 69-68 

: (Uses Depeıdetçies) lali! تبعيات‎ 
69 

التحكم الذاق : 390-9 392 

تحليل ما بعد الحدث : 311-310 

التحليلات الوظيفية: 26 

الترحيل: 2086-7 233-229 245 › 
263-262 


تر کیب البر ميات : 18ء 26-25 38-36 
c47 c45‏ 209 


الترامن : 130-127. 249 
تشانکارینی » باولو : 117 398 
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تشایر» سان مور و جیسان : 220 

تشن ه. ي.: 154 

التصميم : 28 84-83 112» 222 

التصميم كائني التوجه: 34> 138» 166› 
309. 406 

التصميم متعدد المستخدمين : 32 

تطبيق الحوسبة : 29 

تطبیقات A۴1‏ : 53۔ 56 66 69-68 76- 
77 249 

التطبيقات الشاملة : 20-19 

تطبيقات الريب: 19ء 210-201» 213- 
218 223-220 

تطور البر ميات : 18-17 20ء 26ء 28» 
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زمن التنفيذ : 28-27 

زمن ما فبل التنفيذ: 28-27 


- س - 

ستوري» ماغاریت _آن : 295 

سکالي» مایکل : 277 

سکانلان» دیفید : 335 

سکانيللو» غياسبي : 22 

السلوك الديناسيكي : 84 

السلوك المعتمد على الحالة: 19 158 

سمیث» رید: 124 
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ي» ديفيد : 379 

ليمانء ماني : 346 


- - 
مارتینو» سیرجیو دي : 22 
مارياني» ليوناردو : ۰137 401 
ماکابي» توماس: 270 
ماكغريغور» جون: 164 
مالون» توماس : 390 
متحكم عرض النموذح : 208-206» 222 
ال ص فح: 90ء 205-203ء 214-213» 


220-216 

المتغيرات متعددة الأشكال : 35 

محدد مواقع المصادر الو حدة :)0R1(‏ 202- 
205 208« 221 

المحول: 40 

المشاورات : 154 

مشروع بيثات التصميم للتطبيقات الشاملة : 
19 

مصادر المعرفة : 124 

< 180 «174 <46 : (Choreographer) المصمم‎ 
-197 ›195 193-191 ›187-6 
›324 315 309 307 241 18 
394 370 367 41 

المطابقة العلائقية الكائنية : 208 

معاللحة الحالات الاستشائية : 140 

مقاطع الهيكلية : 55» 64 

مقاييس السؤال المستهدف (™@6): 325؛ 
338 


مقاييس المطابقة : 285 

مقیاس ماکاي لدرجة التعقيد السيكلرماق : 
273 

الكوتات البرجية: 38› 54» 66ء 76 80» 
122 235-234 

المكونات البرتجية غير المركزية: 26 

المكونات البرتية المركزية : 26 

المكونات الثابتة : 26 

الكونات الجاهزة للاستخدام: 31» 36» 
c44‏ 54< 60« 76 

المكونات المتخيرة: 26 

منصات البر يات : 52> 54 57 

منصة الإطلاق : 56 

منصة تطوير خدمات الويب الدلال -۸8]) 
٠ 130 :ID‏ 

المنصة المدجة مسبقاً: 64 

المنصة المرجعية المتكاملة : 61 

المنصة المفتوحة: 54 

منهج ھن : 121 

122-121 :Tropos منهج‎ 

منهجبات التطوير السريعة: 22 370 403 

296 : C¥Ssca1 منهجية‎ 

منهجية anم1:‏ 371-370 375 380 › 
390 395 

381 370 : Sr منهجية‎ 

«21 : (eXtreme Programming) XP qi 
› 389-380 378-375 370 368 
395-392 

المنهجية أدواتية التوجه: 128 

منهجية التطوير السريع : 371» 393 

المنهجية الحلزونية : 386 
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206 :5 ۷٣ النموذج‎ 

تیتو» إلیزابیتا دي : 47 

ےھ 


هارتان» جان: 149» 154 

هارولده ماري جین : ۰159 164» 166 
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واجهات رة التطبيقات : 77 
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ویلد» نورمان: 277 


المنهجيات والتقنيات وادارة العمليات 


الحديثة في هندسة البرمجيات" 
السلسلة: 
الكتاب: 
(«) الكتاب الثاني من تقنية المعلومات 
المؤلف: 
1. المياه 
2. البترول والفاز 
3. البتروڪيمياء 
.3 4. النانو 
3 5. التقنية الحيوية 
5 6. تقنية المعلومات 
7. الإلكترونيات والاتصالات 
1 والضوئيات 
1 8. الفضاء والطيران 
¬ 9. ائطاقة 
10. المواد المتقدمة 
11. البيئ 
المترجعة: 


المنظمة الغربية للترجمة 


تضم هذه الساسلة ترجمة لأحدث الكتب عن 
التقنيات التي يحتاج إليها الوطن المربي 4 
البحث والتطوير ونقل الممرفة إلى القارئ 
العربي. 


المرجع الوحيد الذي يقدم للتقنيات المستحدئة 
4 هندسة البرمجيّات وهو يتطرق بلفة ساسلة 
ويسيرة إلى أربعة حقول رئيسة 3 هذا المضمار هي: 
معمارية البرمجياتء وطرائق تأثير البرمجيّات ب4 
الحوسبة الخدماتية وفحص الأشياء وال الا 
وتطوير الشبكة الحديثةء وتقنيات التطوير اوا 
إدارة العمليات حيث يضع u‏ لطراثق ذكية 
وساسلة لمملية الإدارة. 

يمثل كتابنا الحالي مرجماً ب4 الخطوة الأولى 
ممارسي هندسة البرمجيّات ومختصيها كما يعد 
کتاباً ماليا لطلاب الدراسات الجاممعية والمليا على 
حد سواء. 
اندريا دي لوتشياء أستاذ علم الحاسوب ومدير 
المدرسة الدولية الخاصة بهندسة البرمجيات 4ك 
جاممة ساليرنو (إيطائيا). 
فيلومينا فيروتشي: أستاذ مساعد علم الحاسوب 
ومماونة مدير المدرسة الدولية الخاصة بهندسة 
البرمجياتء ومدرسة مادتي هندسة البرمجيات 
ونظم مملوماتية الشبكة 4 جاممة ساليرنو. 
جيني تورتورا: عميدة هيئة الرياضيات والفيزياء 
والملوم التطبيقية 4 جاممة ساليرنو ومؤلفة 
مشاركة 4 کتابین بالاختصاص. 
ماریزیو توتشي: بروفیسوړ مختص بعلم الحاسوب. 
وهومنسق برامج شهادتي البكالوريوس 
والماجستير 4 جاممة ساليرنو. 
مرفت سلمان: ماجستير 2ك أذظ ية إدارة 
المعلومات ‏ جاممهة عمّان المربية للدراسات 
المليا. 
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